It's good to hear from Richard that turning on idle thread reaping is beneficial on the server side, but there's still the issue of leakage on the client side. Even if a worker thread is harvested, which results in closing its socket, the associated socket on the client side would remain in the connection pool until an invoker tries to use it. "galder.zamarreno(a)jboss.com" wrote : | The only reason I could see to leave it as it is would be if creation/connect were noticeable more expensive operations compared to caching it and reusing the same client all the time. I don't see it being much more expensive although the ClientInvoker location done in 2.2.x happens within a big synchronized block. | If the ClientInvoker already exists, control pops out of the synchronized block near the beginning. I agree that turning on idle thread reaping is a good thing, and I agree that avoiding client side leakage is a good thing. The most straightforward way of doing the latter is to use the "invokerDestructionDelay" facility. Here are two related threads: "Remoting issue" in the "Design of EJB 3.0" forum http://www.jboss.org/index.html?module=bb&op=viewtopic&t=130264 and "JBREM-877: New Socket Connection is being Created for Every" in the Remoting Users forum http://www.jboss.org/index.html?module=bb&op=viewtopic&t=126382&a.... Note the following quote from the latter thread: "kiwi_clive" wrote : | Hi Ron, | | Many thanks for your help. We saw an immediate performance gain, halving response time. This has proved to be the single most effective performance enhancement in our tuning efforts so many thanks for providing the fix. | | Most appreciated ! | | Clive | I can think of an alternative: a TimerTask that reaps unusable sockets. But given the preceding quote I'm not sure if it's necessary. -Ron View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222502#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...