This is a discussion on Re: How to differentiate snmpwalk & snmpgetnext request - SNMP ; --===============1433124943== Content-Type: multipart/alternative; boundary="0-9638498-1210313303=:7593" Content-Transfer-Encoding: 8bit --0-9638498-1210313303=:7593 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Yes. It's a tradeoff between consistency and up-to-date information. Finally we have to give up one. ------------------------- Even if we increase the caching time, We can expect a ...
--===============1433124943==
Content-Type: multipart/alternative; boundary="0-9638498-1210313303=:7593"
Content-Transfer-Encoding: 8bit
--0-9638498-1210313303=:7593
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Yes. It's a tradeoff between consistency and
up-to-date information. Finally we have to give up one.
-------------------------
Even if we increase the caching time, We can expect a walk req. just before the expiry of caching time which will lead to refresh of table & inconsistent data if any inst. add/remov-ed.
Thanks to everyone.
Thanks
Valantina
Dave Shieldwrote: 2008/5/8 valantina arumugam :
> 1. Say the cache time is 6 sec & XX Table contains 8 instance.
> snmwalk request comes at 3 rd sec
No.
The loading of the cache would typically be triggered by the first
SNMP request. So the beginning of the snmpwalk request
would mark the *start* of the cache timeout period.
Of course, if it takes longer than 6 seconds to walk the whole table,
then yes - the cache would expire during this traversal, and you
could potentially end up with inconsistent data.
The answer there would be to increase the lifetime of the cache.
This should be set to something slightly longer than the expected
time to walk the table. It's a tradeoff between consistency and
up-to-date information.
Dave
---------------------------------
Meet people who discuss and share your passions. Join them now.
--0-9638498-1210313303=:7593
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
-------------------------
Yes. It's a tradeoff between consistency and
up-to-date information. Finally we have to give up one.
Even if we increase the caching time, We can expect a walk req. just before the expiry of caching time which will lead to refresh of table & inconsistent data if any inst. add/remov-ed.
Thanks to everyone.
Thanks
Valantina
Dave Shield <D.T.Shield@liverpool.ac.uk> wrote:2008/5/8 valantina arumugam:
> 1. Say the cache time is 6 sec & XX Table contains 8 instance.
> snmwalk request comes at 3 rd sec
No.
The loading of the cache would typically be triggered by the first
SNMP request. So the beginning of the snmpwalk request
would mark the *start* of the cache
timeout period.
Of course, if it takes longer than 6 seconds to walk the whole table,
then yes - the cache would expire during this traversal, and you
could potentially end up with inconsistent data.
The answer there would be to increase the lifetime of the cache.
This should be set to something slightly longer than the expected
time to walk the table. It's a tradeoff between consistency and
up-to-date information.
Dave
Meet people who discuss and share your passions. Join them now.
--0-9638498-1210313303=:7593--
--===============1433124943==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757...un.com/javaone
--===============1433124943==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
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/...net-snmp-users
--===============1433124943==--