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

[Fedja Jeleskovic]

> >>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.

I understand! So, where would be the best place to do actuall delete of the
objects that are removed? I mean, right now my code is in the
rowStatus::set() function inside the switch clause. Is there a beter way to
do this?

> >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!

Here I get a bit confused. I did leave the framework to do as much as it
can, but I have to actually set something on the remote machine in order to
have the whole action done correctly. The problem is that I cannot set those
values from the table partially. They have to be all there in order for the
new entry to added. That is why I have a final rowStatus::set() (actually
this is moved to the commit_set_request() instead) to first collect them all
and finally call the function to add new data on that machine.

If my final function fails for any reason (in this case so far, this was due
to the incomplete data), I have to let the framework know it failed, which
leads to the undo action.Maybe if I could check if everything is in order
before I call my final function from the set(), I would not failed in there!
Would prepare_set_request() be a better way to check for the values that I
need and return some error in there so it would never get into the set() or
commit_set_request() functions?

And, could I return something else besides the COMMIT_FAIL error in there?


Thanks


Fedja Jeleskovic