Hi Dave, I see lots of replies from you today, so you had a busy day :-), thanks a lot.
Please see my comments embedded. Thanks, Yong Chen > -----Original Message----- > From: Dave Shield [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 13, 2005 1:22 AM > To: Yong Chen (yongche) > Cc: net-snmp-users@lists.sourceforge.net > Subject: RE: Multiple sets in one pdu > > > 2. For example, I need to set 'b' before I can set 'a'. > > Basically this means in ACTION phase of write_method_a for > a1, I can't > > do anything because b1 is not set yet. > > Not quite - in the ACTION phase for a1, you can't do anything > unless you've already assigned b1. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > But you are perfectly at liberty to make this assignment at > an earlier stage (e.g. RESERVE2). How? Are you saying I can set 'b1' at RESERVE2 (instead of ACTION), then by the time when 'a1' gets to ACTION phase, it can be set since 'b1' was set already in previous pass? But this approach seems to be not scalable. If I have 'a' depending on 'b', 'b' depending on 'c', 'c' depending on 'd', then I need to set 'd' in RESERVE2, and 'c' in ACTION, and 'b' in COMMIT, then there's no pass left for 'a'. > > > 3. Another way is, I can set 'a1' within 'b1' ACTION phase in > > write_method_b (right after 'b1' is set) > > That's certainly an alternative approach. But it seems to be odd to call 'a1' handler from within 'b1's handler, also as I mentioned, if 'a1' handler fails, we will report 'b1' error, not 'a1' error, since we are in 'b1' handler. I understand after RESERVE1, we should have already validated the input varbinds, but we may still see errors at later stage. (Actually when we return an error, do we really associate the error with the offending varbind in response?) > > Another possibility would be to assign a structure to hold a > working copy of the new row (say in the RESERVE2 pass), and > note which is the last varbind referring to that row. > > Then the various ACTIVE processing can update the working row > (without touching the underlying subsystem), and it's only > the "last varbind" that would check the consistency of the > overall assigment, and update the underlying system. Still the same problem, the error will be associated with the last varbind, not the real "offending" varbind. Will 5.x handler style solve this problem? All my varbinds are in the same table so they can have one handler. Also just curious, in 5.x style, since one handler will have a list of varbinds (in requests) as one of its input parameters, if some error happens during processing, do we know in response pdu which varbind caused the problem? > > > > if 'a1' set fails, the error report will report 'b1' > > oid, not oid of 'a1', because it's in write_method_b(). > > As far as possible, you should try to check the validity of > assignments *before* applying them (i.e. in the RESERVE1 pass). > That's not always possible, but is certainly the ideal. > > That way, the error can be associated with the correct varbind. > If it's a problem with inconsistent values (a1=1, b1='z') > then it doesn't actually matter which one gets the blame :-) > > > Dave > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
