Stateful Session Bean memory leak in AS 7.1.1 (win 7, redhat linux)

[maderhan]

Hi,

I have got a SFSB running on 7.1.1 standalone.

The SFSB has been migrated from ejb2 to ejb3.1 (Home, Remote, Bean impl., ejb-jar.xml).

Passivation on server is NoPassivate (simple).

The client calls come from a tomcat 7.

After running a time with a number of remote calls, the AS 7 vm is out of memory.

Force GC does not free the jvm memory pool "tenured gen" on windows or "ps old gen" on linux!

Only when I disable the Bean, the memory is freed.

Client:

                Properties jndiProps = new Properties();
                jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
                jndiProps.put("jboss.naming.client.ejb.context", true);
                jndiProps.put(Context.PROVIDER_URL,"remote://myserver:4447");
                jndiProps.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

                jndiProps.put(Context.SECURITY_PRINCIPAL, "username");
                jndiProps.put(Context.SECURITY_CREDENTIALS, "password");

                InitialContext context=new InitialContext( jndiProps );

               PortalHome pHome = (PortalHome)c.lookup("ejb:/PortalBean/PortalBean!uiportal.ejb.session.PortalHome?stateful");

               Portal pRemote = pHome.create();

               pRemote.doSomeStuff();

               pRemote.ejbRemove(); // Bean Method annotaded with @Remove, also in Remote Interface -> the @PreDestroy method will be called by the server!!!!

               context.close();

Any idea is highliy appreciated!!!!

Thanks.

[nickarls]

Have you tried if this is reproducible on a nightly build? What if the client call is from a Java SE standalone client?

[maderhan]

Client call comes from Java SE 1.7.0_07:

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

                Properties jndiProps = new Properties();
                jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
                jndiProps.put("jboss.naming.client.ejb.context", true);
                jndiProps.put(Context.PROVIDER_URL, "remote://myhost:4447");
                jndiProps.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

                jndiProps.put(Context.SECURITY_PRINCIPAL, "*");
                jndiProps.put(Context.SECURITY_CREDENTIALS, "*");

                InitialContext context = new InitialContext(jndiProps);

                PortalHome pHome = (PortalHome) context.lookup("ejb:/PortalBean/PortalBean!uiportal.ejb.session.PortalHome?stateful");

                Portal pRemote = pHome.create();

                System.out.println(i + "-call..."
                        + pRemote.getUserEmail("MYFRIEND"));

                pRemote.ejbRemove(); // Bean Method annotaded with @Remove, also in Remote Interface -> the @PreDestroy method will be called by the server!!!!

                context.close();
            }

Exactly the same behaviour:

1) Client calls - memory increase - GC has no effect (to pool tenured gen or Instances of SFSB)

2) SFSB disable/enable

3) GC

I  compared two heap dumps (before/after) - 10.001 calls: you can see the remaining objects in context to the calls

[maderhan]

Regarding the nightly build: No I did not try any. Which version should I take? Could you provide a URL for me please.

Since we deployed the SFSB on production (and we could not step back to jb 5 / ejb 2.1) we have to stop/start once a day.

Increasing the vm memory params helped us a little...

[jaikiran]

Can you please post your bean code too?

[jaikiran]

Hans-Dieter Mader wrote:

Regarding the nightly build: No I did not try any. Which version should I take? Could you provide a URL for me please.

It's here https://community.jboss.org/thread/167590

[maderhan]

jaikiran pai schrieb:

Can you please post your bean code too?

Please note: The code is reduced!

[maderhan]

Nicklas Karlsson schrieb:

Have you tried if this is reproducible on a nightly build? What if the client call is from a Java SE standalone client?

Now I tried the same Java SE client with

jboss-as-7.2.0.Alpha1-SNAPSHOT

but with the 7.1.1 jboss-client.jar

-> Same behaviour as described

When I tried to use the 7.2.0 jboss-client.jar  I got the exception:

javax.naming.NamingException: Failed to create proxy [Root exception is java.lang.NullPointerException]
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:115)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.magnasteyr.josf.mock.Main.main(Main.java:42)
Caused by: java.lang.NullPointerException
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:347)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:228)
at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:238)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:160)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)

[nickarls]

Try using the matching jboss-client.jar version. What is it that ends up null? pHome?

[maderhan]

Nicklas Karlsson schrieb:

Try using the matching jboss-client.jar version. What is it that ends up null? pHome?

I used the matching jboss-client.jar.

The ref. to the Home Interface is null - pHome.

[nickarls]

Shouldn't you lookup the remote interface?

(not that I use remote EJBs in my project)

[maderhan]

Nicklas Karlsson schrieb:

Shouldn't you lookup the remote interface?

(not that I use remote EJBs in my project)

Nicklas,

you brought me a good idea.

When I migrated the ejb from 2x to 3x, I did not care about Home and Remote interfaces.

What I have done right now:

1) Moved the special create methods from Home Interface to Remote Interface.

2) JNDI lookup for Remote Interface Ref. (not for the Home!!!!)

3) Removing the Home Interface definition from ejb-jar.xml.

                       Properties p = new Properties();
                  
                       p.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
                       p.put("remote.connections", "default");
                       p.put("remote.connection.default.host", "myserver");
                       p.put("remote.connection.default.port", "4447");
                       p.put("remote.connection.default.username", "*");
                       p.put("remote.connection.default.password", "*");           
                       p.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
                       p.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
                       p.put("remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS", "true");
                       p.put("remote.connection.default.connect.timeout", "30000");//for xnio
               
                      EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(p);
                      ContextSelector<EJBClientContext> selector = new ConfigBasedEJBClientContextSelector(cc);
                      EJBClientContext.setSelector(selector);
       
                      Properties props = new Properties();
                      props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
                      InitialContext context = new InitialContext(props);
               
               
                     for (int i = 1; i <= l.longValue(); i++) {
                   
                          Portal pRemote=(Portal)context.lookup("ejb:/PortalBean/PortalBean!uiportal.ejb.session.Portal?stateful");               

                          pRemote.ejbCreate(); // special initialization
                 
                          System.out.println(i + "-call..."
                                  + pRemote.getUserEmail("TEST"));

                           pRemote.ejbRemove(); // Bean Method annotaded with @Remove, also in Remote Interface -> the @PreDestroy method will be called by the server!!!!

               
               
                    }

           context.close();

I performed testing on 7.1.1 and 7.2. ALPHA.

And it looks very good - No memory leak at this time.

What's the basic difference between using the Properties (see first post) and the connection properties in this post?

[maderhan]

I just tried the InitilContext lookup way to do...              

               final Properties jndiProps = new Properties();
                jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
                jndiProps.put("jboss.naming.client.ejb.context", true);
                jndiProps.put(Context.PROVIDER_URL,"remote://myhost:4447");
                jndiProps.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

                jndiProps.put(Context.SECURITY_PRINCIPAL, "*");
                jndiProps.put(Context.SECURITY_CREDENTIALS, "*");

               InitialContext context = new InitialContext(props);

               for (int i = 1; i <= 10000; i++) {
                   
                          Portal pRemote=(Portal)context.lookup("ejb:/PortalBean/PortalBean!uiportal.ejb.session.Portal?stateful");               

                          pRemote.ejbCreate(); // special initialization
                 
                          System.out.println(i + "-call..."
                                  + pRemote.getUserEmail("TEST"));

                           pRemote.ejbRemove(); // Bean Method annotaded with @Remove, also in Remote Interface -> the @PreDestroy method will be called by the server!!!!

               
               
             }

           context.close();

The memory leak seems to be gone!!

I guess the point is to lookup the remote Interface, not going the way via the Home Interface.

Which way would you prefer for accessing remote sfsb's? (EJBClientContext OR InitialContextFactory)

I found some very interesting here:

https://github.com/jaikiran/jboss-ejb-client/compare/b1168156e4613dd0402357c889954e3a5f2a49fe...ejbclient-34