2 Replies Latest reply on Sep 25, 2012 12:29 PM by gilby

    Remote JNDI Thread Leak?

    gilby

      Following the directions provided by https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI, I successfully created a remote JNDI client. However, while running some performance tests, I discovered that the number of threads spawned by my test client kept rising, until I received this error:

       

      java.lang.OutOfMemoryError: unable to create new native thread

      at java.lang.Thread.start0(Native Method)

      at java.lang.Thread.start(Thread.java:658)

      at org.xnio.nio.NioXnioWorker.start(NioXnioWorker.java:145)

      at org.xnio.nio.NioXnio.createWorker(NioXnio.java:127)

      ...

       

      Below is the code that caused the OutOfMemoryError on the client side. I do realize I can perform a single JNDI lookup of my interface outside of the for loop, but I wanted to get a feel for the overhead associated with obtaining a remote JNDI context.

       

              for (int i = 0; i < 500; i++) {
                  long start = System.currentTimeMillis();
                  Context context = null;
                  try {
                      Properties ejbProps = new Properties();
                      ejbProps.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
                      ejbProps.put("remote.connections", "default");
                      ejbProps.put("remote.connection.default.host", "localhost");
                      ejbProps.put("remote.connection.default.port", "4447");
                      ejbProps.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
                      EJBClientConfiguration ejbClientConfiguration = new PropertiesBasedEJBClientConfiguration(ejbProps);
                      ContextSelector<EJBClientContext> ejbClientContextSelector = new ConfigBasedEJBClientContextSelector(ejbClientConfiguration);
                      EJBClientContext.setSelector(ejbClientContextSelector);
      
                      Hashtable<String, String> properties = new Hashtable<String, String>();
                      properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
                      context = new InitialContext(properties);
                      
                      String jndiName = "ejb:ear_name/ejb_jar_name/BeanName!fully.qualified.RemoteInterfaceName";
                      RemoteInterfaceName remoteInterface = (RemoteInterfaceName) context.lookup(jndiName);
                      remoteInterface.doSomething();
                  } catch (NamingException ne) {
                      throw new RuntimeException(ne);
                  } finally {
                      if (context != null) {
                          try {
                              context.close();
                          } catch (NamingException e) {
                              // meh
                          }
                      }
                  }
                  
                  //...
              }
      

       

      By the time this code blew up, it had spawned over 2,000 threads. While debugging it, I noticed that 6 threads were created each time ConfigBasedEJBClientContextSelector was created. Is this a bug, or is it mandatory for remote clients to manually cache remote interfaces obtained in this manner?

       

      Thanks for your help!