First, the EPR is on a per service basis, not a per thread basis. Threads are an implementation issue that should not be exposed to users/clients. If there are hundreds of threads working on behalf of a given service (aka business logic), it would be wrong to then have hundreds of EPRs. In some ways I agree with Esteban, but in others I think this is related to the thread pool issue. I'm assuming that irrespective of the reloading issue, there is a single listener thread at the "bottom" of the hierarchy that does the registration for the service and all it does upon receipt of a message is to spawn a new worker thread. That's pretty much what most distributed systems have been doing since the mid 1990's when threads (or lightweight processes as they were known then) became more widely available. Assuming we follow this model and ignore reload for now, then we should be fine. Now back to the reload issue. As I've said before, I think there are good reasons for reloading and reinstantiating the configuration/setup, but that is an implementation specific concern for services. It shouldn't be something that is mandated for all listener implementations. In fact, by default I think all that should happen is a reload of the parameters and if anything has changed we trigger an event and leave it up to the event handler to figure out. If that handler wants to re-instantiate, then it's up to it to figure out how to do it without screwing up anything else. We could provide a handler for JMS, but does anything else really need it at the moment? Assuming we can agree on what the issue(s) is(are) and potential solutions, the next question is: what can we do for the GA that is quick and gives us a solution? It may not be the best solution, but we can revisit that after the release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990787#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...