[SNMP4J] Table Listeners and multi-threading

[pasteman8-agentpp at yahoo.com]

Thanks again, you helped me a lot.

So basically I understand that a design of TableUtils
per thread is safe, both from the MT aspect and both
from the performance aspect.
If each thread is also a listener, it will also
separate the event handling and make it per-thread.

There is a basic question regarding the design of
TableUtils:
Can the getTable method be used in a runnable run()
method? In otherwords, does getTable return only when
the table is done?

+gil

--- Frank Fock <fock at agentpp.com> wrote:

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