[AGENT++] Problem with READ-CREATE tables...

[Frank Fock]

Hi Fedja,

Please find my comments inline:

Fedja Jeleskovic wrote:

>>I recommend to move any code that returns an error code
>>from the commit_set_request to the prepare_set_request
>>method (in your example this seems to be true for most
>>of the code).
>>    
>>
>
>I did move most of the code to the commit_set_request(), but my rowDestroy
>stoped working and I had to move that part back to the set() method...
>
>  
>
That's no problem, as long your row destroy does not return with an error.
When destroying a row however, you need to be careful, because you must not
free the row while it is used by the AGENT++ framework. Handling this is 
a bit
tricky. You can have a look at the MibTable and snmpRowStatus classes for
more details. In general, letting snmpRowStatus do the RowStatus handling is
the best and easiest way.

>But, there is another problem related to the whole issue that I've
>experiencing for a while. In my example that I used so far, the table had
>only three elements (index, real object, row status). In my real code, I
>have several more real object and if during the row set preparation I miss
>to set one of them and try to do another set, the agent crashes while doing
>the undo on something that doesn't exist. Here is what happens:
>1. I set the row status to createAndWait(5) with new index value.
>2. I set all of the "real objects" in the table one by one using the same
>index value.
>3. I set the row status to active(1)
>
>Now, if I miss to set one of the real objects and row is incomplete, the
>final rowStatus set to active state returns commit failure. But if at that
>time you attempt another set to active for the rowStatus, you get a crash in
>the agent while attempting the undo on something that is not there. In
>particular, crash happens at the SnmpInt32::operator long() const { return
>(long) smival.value.sNumber; }; line which was called from the
>snmpRowStatus::unset() function from the second line ( rs =
>*(SnmpInt32*)undo;). Apparently undo object is gone after the first commit
>failure, another set attempt crashes.
>
>  
>
The undo value is created through each SET operation (two phase commit). 
I have found a bug
in AGENT++ where the undo value is not deleted properly when undoing a 
createAdnWait.
This will be fixed in the next release which I expect to be released 
until Thursday.
However, this bug should not appear in your agent, because an undo is 
always a bad thing
(2PC failed). Yous should once again check your set() and 
commit_set_request() methods
whether and in which situations they return an error.

Returning an error from these "committing" methods should be the last 
resort only!

Best regards,
Frank