[SNMP4J] Table Listeners and multi-threading

[Frank Fock]

Please find my comments inline:

pasteman8-agentpp at yahoo.com wrote:

>Hi,
>
>Thanks for the quick reply, Frank.
>Ok, Let's say I use multiple TableUtils. Each one runs
>in it's own thread and is basically responsible for
>getting one table.
>Is such a configuration even possible? What keeps the
>  
>
Yes, of course.

>thread 'alive' after sending a genext request? ( I
>realize that this is a basic question about the
>TableUtils design.).
>  
>
Nothing keeps the the thread alive. As I tried to explain in my previous
email, the callback is called within the context of the thread that listens
on the UDP/TCP port for incoming packets. This thread is alive as long
as your Session (i.e. the Snmp instance) is not closed.

>If I use this configuration, will all the threads use
>the same listener or is it better to use each thread
>as its own listener? Will it make a difference? If I
>  
>
It makes a difference, because with a TableUtils per thread, you can be
sure which event belongs to which request. Otherwise you will have to
decide this via the userObject.

>use a 'shared' listener I will probably have to use
>the user object to indicate which thread sent the
>original request when an event occures.
>  
>
Correct.

>I believe that a design like this requires a simple
>walk of the table which is ok but it will be a shame
>not to use the TableUtils that are already there...
>
>  
>
Best regards,
Frank

>+gil
>
>--- Frank Fock <fock at agentpp.com> wrote:
>
>  
>
>>Hi,
>>
>>A straight-forward approach would be using multiple
>>TableUtils
>>instances. So you can separate the callbacks easily.
>>However
>>in any case the callback will be executed in the
>>context of the
>>port listener thread of the used TransportMapping or
>>if you
>>use the MultithreadedMessageDispatcher it will be
>>the context
>>of one of the threads in the
>>MultithreadedMessageDispatcher's
>>thread pool.
>>
>>A "centralized" callback handler can be realized by
>>a singleton class
>>that implements the TableListener interface, however
>>the callback
>>will still be executed in the thread context of the
>>event firing thread.
>>
>>To map an event to your thread, you will have to
>>implement a queue.
>>
>>Hope this helps.
>>
>>Best regards,
>>Frank
>>
>>pasteman8-agentpp at yahoo.com wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>My question is this:
>>>If I use table utils in a multithreaded application
>>>      
>>>
>>in
>>    
>>
>>>a way that each thread is set to retrieve a table
>>>      
>>>
>>by
>>    
>>
>>>using table utils, I assume that each thread will
>>>      
>>>
>>also
>>    
>>
>>>be a listener and will get its own callback called
>>>when a row is read from the table.
>>>My question is:
>>>1. Is there a way to make a 'centralized' callback?
>>>      
>>>
>>I
>>    
>>
>>>assume that there is, technically, by using a
>>>      
>>>
>>static
>>    
>>
>>>method and passing the correct user object to it or
>>>some other way maybe (If anyone has a good idea, I
>>>would be happy to hear it). The question is if this
>>>thing can work properly.
>>>2. If the callback is per-thread, is it more or
>>>      
>>>
>>less
>>    
>>
>>>efficient that using a standard 'walk' for the
>>>      
>>>
>>table
>>    
>>
>>>instead of using a listener. What about a 'central'
>>>callback in terms of efficiency?
>>>
>>>Thanks,
>>>G
>>>
>>>_______________________________________________
>>>SNMP4J mailing list
>>>SNMP4J at agentpp.org
>>>      
>>>
>>http://p15141779.pureserver.info/mailman/listinfo/snmp4j
>>    
>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>
>
>
>  
>