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

[Fehde, Marcus]

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


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
Url: http://lists.agentpp.org/pipermail/agentpp/attachments/20040722/04696a7d/attachment.txt