[jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Server side thread leak?
galder.zamarreno@jboss.com
do-not-reply at jboss.com
Mon Mar 30 09:03:40 EDT 2009
Re: https://jira.jboss.org/jira/browse/JBAS-6665
Ron/Richard, is this happening in clustered or non clustered tests? Or both?
My thoughts:
Unified invokers (read EJB2) do not work like the the EJB3 ones. The unified one caches client in the very 1st invocation and uses that all the time (versus create/connect/disconnect for every invocation). In the case of clustered unified invoker, every time a new locator is used, a new client is created and used. While the same locator is used invocation after invocation, the same client is used. When the locator changes, a new client is created and connected to.
Not sure whether EJB2s should work exactly the same as EJB3s. In the case of non-clustered unified invoker, caching and reusing the same client all the time would probably yield better performance. When would we call disconnect in this case? Dunno right now.
In the case of clustered invokers, I think disconnecting the current client before creating/connecting a new one would make sense as otherwise you're leaking clients (this probably needs a jira, FAO Brian thoughts?)
Finally, why is the default value not to run the idle timeout task? For EJB2 non clustered beans, with current design, this idle timeout functionality should be enabled if we wanna leave it as it is. Actually, probably with clustered as well, (i.e. SFSBs that have first available lbp).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221979#4221979
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221979
More information about the jboss-dev-forums
mailing list