[AGENT++] NoSuchInstance in case of an unavailable row within atable

Frank Fock fock at agentpp.com
Thu Jul 22 09:45:37 CEST 2004


Hi Marcus,

I would have prefered that you overwrite the get_access() method
and call the get_request of your leaf from there. But you surely
have your reasons why this does not work properly.

Changing the GETNEXT processing this way will work, and I do
not see any problems, except that
1. You will have the call entry->end_synch() before you jump to AGAIN.
2. You will also have to change the GETBULK processing which is
more complex ;-)

Best regards,
Frank

Fehde, Marcus wrote:

>Hi Frank!
>
>I just tried my suggestion and it seems that it works.
>The modifications within process_request:
>
>case (sNMP_PDU_GETNEXT): { 
>  .
>  .
>  .
>  MibEntryPtr entry;
>  Oidx tmpoid(req->get_oid(reqind));
>AGAIN:                                 <=======
>  lock_mib();
>  .
>  .
>  .
>  req->set_oid(tmpoid, reqind);
>  entry->start_synch();
>  unlock_mib();        
>  entry->get_next_request(req, reqind);
>        
>  if( req->get_value( reqind ).get_exception_status() == sNMP_SYNTAX_NOSUCHINSTANCE )
>    goto AGAIN;
>          
>  entry->end_synch();
>  .
>  .
>  .
>
>The tmpoid is moved to the next instance / successor on every loop.
>
>
>Even though it does the processing as I want it to do in my scanerio, I'm absolutely not sure about the side-effects.
>Please can you assess this modification?
>
>Regards
>Marcus
>
>-----Original Message-----
>From: agentpp-bounces at agentpp.org [mailto:agentpp-bounces at agentpp.org] On Behalf Of Fehde, Marcus
>Sent: Donnerstag, 22. Juli 2004 07:11
>To: Frank Fock
>Cc: agentpp at agentpp.org
>Subject: RE: [AGENT++] NoSuchInstance in case of an unavailable row within atable
>
>
>Hi Frank,
>
>both methods of resolution are not sufficient, because the earliest point where I can determine whether the instance is accessible or not is within the get_request method of the leaf. 
>So if I want to skip the leaf at this late point I think I've to change the process_request method of Mib. The first part of this method does the successor search and accessibility checks, then the get-next method is called. If the call to the method does not have any result the process has to go back to the beginning and look for the next successor.
>
>How do you handle this in the row creation scenario? As far as I now a newly created row that has no default values causes a noSuchInstance exception. Or is the Agent++ implementation different in this point and always assuming a default value (provided by the data containing in the cloned leafs)?
>
>I do really hesitate to change the request processing in our agent, because I'm sure that a can estimate all side effects of this change. On the other hand I don't want to cancel a table traversal only because of a not accessible leaf (behind this leaf might be some kind of hardware as sensors, actuators, etc. that is sometimes not available for any reason).
>
>Do you have any further ideas?
>
>Regards
>Marcus
>
>-----Original Message-----
>From: Frank Fock [mailto:fock at agentpp.com] 
>Sent: Mittwoch, 21. Juli 2004 19:14
>To: Fehde, Marcus
>Cc: agentpp at agentpp.org
>Subject: Re: [AGENT++] NoSuchInstance in case of an unavailable row within a table
>
>
>Hi Marcus,
>
>You will have to overwrite the MibTable::find_next(const Oidx&) method and return 0 if you cannot find a successor in your table. Normally you would have overwritten MibEntry::find_succ(const Oidx&), but MibTable is handled different than other MibEntry subclasses (for historic reasons). This should/will be sort out in a future release. By overwriting find_next today you will be safe in any case.
>
>If you do not want to overwrite MibTable::find_next because the information you need to decide whether an instance is available or not is rather 
>local to
>your MibLeafs than to the table, then you could overwrite the 
>MibLeaf::get_access()
>method too and return NOACCESS in case you want to skip it.
>
>Best regards,
>Frank
>
>Fehde, Marcus wrote:
>
>  
>
>>Hi!
>>
>>I've a table of MibTable with derived MibLeaf instances as columns. The
>>get-method is overloaded and retrieves always the current value of 
>>something. If I can't retrieve the current value a want to return a 
>>noSuchInstance exception to mark the row or single cell as currently 
>>unavailable. I did it this way: vb.set_syntax( sNMP_SYNTAX_NOSUCHINSTANCE ) : vb was taken from request
>>
>>The problem is that the agent does not try to retrieve the next
>>available instance, but responses the OID contained in the 
>>GETNEXT-request. The result is that my MIB browser does an endless loop. The exception is included in the response varbind.
>>
>>Can somebody tell me what the problem is?
>>
>>Best regards/Mit freundlichen Gruessen
>>
>>Marcus Fehde
>>Dipl. Ing. Technische Informatik (FH)
>>
>>Research & Development
>>Business Unit Anaesthesia
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>>
>>DRÄGER MEDICAL
>>
>>Dräger Medical AG & Co. KGaA
>>Moislinger Allee 53-55
>>D-23542 Lübeck 
>>
>>Tel:  + 49-451-882-3646
>>Fax: + 49-451-882-4410
>>E-mail: marcus.fehde at draeger.com 
>>www.draeger-medical.com 
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>>
>>
>>
>> 
>>
>>-----------------------------------------------------------------------
>>-
>>
>>_______________________________________________
>>AGENTPP mailing list
>>AGENTPP at agentpp.org http://agentpp.org/mailman/listinfo/agentpp
>> 
>>
>>    
>>
>
>
>  
>





More information about the AGENTPP mailing list