Remote JNDI Thread Leak?
gilby Sep 24, 2012 8:12 PMFollowing 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!