A semi-nasty wrinkle that occurred to me as I wrote the above: For a container involving sessions or other long running units of work, we want to allow new requests for that session until it has expired/been removed/been replicated. This is the work of the acceptor, which needs to interact with the container to track the status of sessions. But actually it's only interested in sessions associated with its endpoint. The fact that calls coming in via some other endpoint are keeping sessions alive shouldn't prevent the acceptor completing its stop method. Perhaps this isn't a huge issue; e.g. if a SFSB takes requests via a Remoting connector and also via the web tier, there are 2 acceptors involved -- the SFSB's and the web app's. If the shutdown is multithreaded, stop() can proceed on both in parallel. So all sources of new sessions will be cut off and eventually and the SFSB+Remoting acceptor can complete stop(). This requires multithreaded shutdown though. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267394#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...