Hi Frank, You are right, double pooling would not make sense (having ThreadPool getting threads from the server was not a good idea), but it is not my aim. My main concern is not to start application-threads in a J2EE environment. Starting applications threads is unsupported and sometimes not allowed by J2EE servers. There seems to be various reason for that: the container is unaware of application-threads and will not be able to control them/shut them down, transaction support, cluster support, resource allocation management on server, scalability,...). According to EJB 2.1 specifications it is not allowed, according to servlet 2.3/2.4 it is unsupported and not recommended.
Thus, maybe ThreadPool could become an interface, and, this way, we could have an implementation using server resources (a J2EE compatible ThreadPoolImpl) and pass it to the MultiThreadedMessageDispatcher constructor. Do you thing that could be a solution? I will have a look a SNM4J-Agent. Thanks Regards Brice (some links on the application threads in J2EE topic: http://www.theserverside.com/discussions/thread.tss?thread_id=44353 http://stackoverflow.com/questions/533783/why-spawning-threads-in-j2ee-container-is-discouraged http://www.onjava.com/pub/a/onjava/2004/10/13/j2ee-timers.html?page=1 http://e-docs.bea.com/wls/docs100/programming/topics.html ) _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
