What could be the consequence of not closing EJB client context?

[mac2009]

Hi all,

I would like to know what can happen if someone doesn't close the EJB client context properly (as described here Scoped EJB client contexts - JBoss AS 7.2 - Project Documentation Editor).

Or a bit more in detail:

Is it possible that the unclosed client context causes something like waiting threads?

Thread dump contains a lot of threads waiting for

....

"ajp-bio-18009-exec-859" daemon prio=10 tid=0x00002b22cc4de000 nid=0x75c7 in Object.wait() [0x00002b22fc30e000]

   java.lang.Thread.State: WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    - waiting on <0x00000007de052208> (a java.lang.Object)

    at java.lang.Object.wait(Object.java:503)

    at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:397)

....

System: JBoss EAP 6.2, Tomcat 7.0.52

Best regards

Carsten

[wdfink]

It depends on the use-case.

In general a JNDIContext is a resource and must be closed after use

But for a simple IC the Client-Library might cache the connections. In other use-cases (i.e. remote-naming and scoped-context) the IC mut be closed, otherwise the connections are not closed, or only closed by GC (finalize). In this case you might run in connection or memory issues as the IC hold references to connections and objects.

[mac2009]

Thanks Wolf-Dieter, we will see if behaviour changes after adding the close for the ejb client context.

Probably you can tell me where I can find a good (?) documentation of thread pool configuration (subsystems threads and ejb3).
So far I have read the Administration and Configuration Guide (16.2 and 20.3) but I am missing some more details.

When is it necessary to configure the subsystem 'threads' (only if http clustering or load balancing is required)?

Do you have suggestions for the thread-pool configuration in a production environment? (default value for max-threads is 10)

[wdfink]

Thread pools configuration depend on your requirements and the resources of your system.

In general you should measure and monitor whether your changes has the effect you want. A reason to separate pools might be to restrict i.e. timer events to a lower number of threads to drop the interactive performance. Also you might enlage the available threads for request handling if the machine power is big enough, too much threads can cause performance problems if the machine can't handle it.