Esteban: Johan, Other listeners that are triggered from the GpListener face a situation that is similar to what you're talking about. They can only do so because there is no problem in having more than one instance of the class. The JmsQueueListener is a good example: it could wait forever to obtain a message from a JMS queue. Instead of this it will wait at most until the GpListener is about to reload it's parameters. (See receive() method in JmsQueueListener.java lines 107 to 111 where it determines how much to wait and when to end looping). If a message was received (or an HttpRequest in your case) before that time is expired, it will instantiate the corresponding action class (it has now evolved into a sequence of actions) in a child thread. Once the time has come for the GpListener to reload it's parameters, the JmsQueueListener receive() method will end, and so will the thread in which it's running. In this class, there's really no conflict in having two or more instances of JmsQueueListener. The situation is slightly different when you are listening and (more importantly) responding in a well known port. In that case, you don't wish to have anybody else (not even other instances of the class that's listening) using the same port, until the running instance ends, and so does any class that needs the port. So we would have to think of a mechanism ( e.g. a 'singleton=true' in configuration) to enable some 'controlled' listeners (those that are instantiated from the GpListener) to wait for active instances to finish before re-instantiating with the values that came from the latest parameter reload. Whereas the GpListener class would have to change to reflect this requirement, it would still be essential to allow for some kind of parameter reloading mechanism, and whatever that might be (synchronous or asynchronous), we would still have to deal with the same situation: a sequence of actions that is still working and needing to respond in a specific port, and some new instance of a listener trying to use the same port. Current behaviour of the GpListener does not affect child listeners that don't need to be singletons. It doesn't matter how many processes are polling the same directory as long as they don't step on each others' toes (for example by trying to process the same file). Same with SqlTablePollers and even easier with JmsQueueListeners. My recommendation would be to continue to test your Http listener class, triggering action classes that will process the request and at some point submit a response. In order to do that, and avoiding the noise of parameter reloading, simply put a huge value in parameterReloadSecs attribute. That will temporarily allow you to tune your Http listener, while we think of (and hopefully put in place) an acceptable solution for the GpListener. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975456#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...