-
1. Re: What could be the consequence of not closing EJB client context?
wdfink Jan 6, 2015 3:55 PM (in response to mac2009)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.
-
2. Re: What could be the consequence of not closing EJB client context?
mac2009 Jan 7, 2015 4:37 AM (in response to wdfink)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)
-
3. Re: What could be the consequence of not closing EJB client context?
wdfink Jan 9, 2015 1:25 AM (in response to mac2009)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.