http://www.ashishpaliwal.com/blog/2008/12/multi-threaded-trap-receiver-using-snmp4j/ From Programmer, For Programmers Mon, 09 Jan 2012 04:02:36 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://www.ashishpaliwal.com/blog/2008/12/multi-threaded-trap-receiver-using-snmp4j/comment-page-1/#comment-15529 Dude Tue, 13 Jul 2010 13:47:20 +0000 http://www.ashishpaliwal.com/blog/?p=231#comment-15529 Yeah that's great - multi-threaded. You should point out though that if you want to guarantee processing of the traps in the order they were received (for example, if you are monitoring transitions in state which is what Traps are all about...), this approach is not recommended. Why? Because, when processing the traps via a threadpool or similar concurrent fashion, you cannot guarantee they will be processed in the order they were received. Rather, we would only be assuming they will be processed in the order they are received due to the length of time between each trap being received being large enough under normal operation such that the probability of processing the second trap before the first becomes almost nill. However this is still only an assumption. When freak network behavior occurs, as is common during large outages when floods of traps are being generated, this assumption often leads to unpredictable results (and at a moment when the network needs the solution to be most accurate..). Yeah that’s great – multi-threaded. You should point out though that if you want to guarantee processing of the traps in the order they were received (for example, if you are monitoring transitions in state which is what Traps are all about…), this approach is not recommended. Why? Because, when processing the traps via a threadpool or similar concurrent fashion, you cannot guarantee they will be processed in the order they were received. Rather, we would only be assuming they will be processed in the order they are received due to the length of time between each trap being received being large enough under normal operation such that the probability of processing the second trap before the first becomes almost nill. However this is still only an assumption. When freak network behavior occurs, as is common during large outages when floods of traps are being generated, this assumption often leads to unpredictable results (and at a moment when the network needs the solution to be most accurate..).

]]>