Leo Sutic wrote:
Additionally, since GC isn't predictable, you may run out of pooled objects real fast.
Consider a DB app with a connection pool of 24 connections, and 1GB of free heap.
It processes ten requests per second and each request uses up 10MB of memory. This means that it will take 100 requests to use up the memory, but only 24 to use up the connections, by which time the JVM won't GC since you have 760MB of heap left to much through.
Sure, you can run GC like a nutter in the background, but this seems a bit severe.
And unnecessary. What I'm looking into is how a pool can interact with a memory management service taking into account pool expansion, collection policies and so forth.
I think we came up with the following last time:
Two choices:
1. manager.release() - as it is now.
2. Require that each service interface that can have a pooled implementation (SAXTransformer, Connection, etc.) has one method (endDocument(), close(), etc.) that, after it is called the component can return to the pool safely.
What I'm currently testing provides full support for the ServiceManager.release() - i.e. active consumer driven release. Behind the scenes I'm providing the possibility for passive release (i.e. decomissioning handled by the container in the event that a component has not been actively released but is no longer referenced). A component author can employ an active release when appropriate - and that makes things simpler for developers who are dealing with applications invoking lots of singleton type components.
The potential issue here (that we discussed way back) concerns the fact that a component lifestyle is not assured. So basically the consuming component does not know if service implementation is pooled or not - and as such, non-release of a component could lead to a breakdown because the pool capacity reaches a maximum.
There are two aspects which I think change this conclusion ...
(a) the notion of active versus passive release
(b) the ability of a pool implementation to partitipate in
passive decommissioning when requiredAnd one factor that is driving my attention here - with Merlin 3 we can really easly manipulate the deployment info, add and remove compoents and containers, deploy, undeploy, redeploy etc. All of this in the context of a single long running JVM. That introduces a bunch of concerns related to long-term memory management. In turn that raises the issue of the relationship between component management and memory management.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
