[wildfly]EJBClientContext leak: EJBClientContext is not unregistered from TCCLEJBClientContextSelectorService when it's closed

[lcheng_nj]

I ran into the EJBClientContext leak issue. The call steps are very simple

1. Initialize one Initialize with following ejb related setting

    Properties props = jndiAnalyser_.getJNDIConfig();

     ....

    props.put("jboss.naming.client.ejb.context", true);

    props.put("org.jboss.ejb.client.scoped.context", true);

   InitialContext context = new InitialContext(props);

2. Look up ejb "myear/MyBean!com.test.myClass" from context

3. Invoke some ejb method

4. Close conext

After debugging wildfly source code, I found following cause of EJBClientContext leak

At step1, EJBClientContext is created at RemoteNamingStoreEJBClientHandler.setupEJBClientContext, meanwhile, this EJBClientContext instance is registered within TCCLEJBClientContextSelectorService.

At step4, the EJBClientContext instance is closed via RemoteNamingEJBClientContextCloseTask. However, this EJBClientContext instance is still cached by TCCLEJBClientContextSelectorService, and this make EJBClientContext leaked.

I looks like one wildfly bug. Any comment

[lcheng_nj]

Ok. After debugging wildfly source code, I realize the the reproduce steps are very simple. After running following standalone code, you can check the JVM, there are 10 EJBClientContext instances in the heap and could not be GC.

import java.util.Properties;

import javax.naming.Context;

import javax.naming.InitialContext;

public class EJBClientContextLeakTest {

    public static void main(String[] args) throws Exception {

        for (int i = 0; i < 10; i++) {

            Properties props = new Properties();

            props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

            props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS","JBOSS-LOCAL-USER");

            props.put("jboss.naming.client.ejb.context", true);

            props.put("org.jboss.ejb.client.scoped.context", true);

            props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

            props.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");

            props.put(Context.SECURITY_PRINCIPAL, "vtbaadmin");

            props.put(Context.SECURITY_CREDENTIALS, "vitria");

            InitialContext context = new InitialContext(props);

            context.close();

       }

    }

}

[wdfink]

Hi,

if you are using scoped-context (note that this will be replaced in a future version- because of drawbacks) it is necessary to handle the close different as the EJBClient.

You need to add context.lookup("ejb:") and close this context!

This will solve the issue. It depends on the JNDI approach and there is no other solution for this.

I recommend to not use scoped context but the jboss-ejb-client.properties or the ejb-client API (WildFly specific)

[jaikiran]

Which exact  version of WildFly server is this?

[lcheng_nj]

Thanks. We change the ejb-client way now