The references to delegators isn't the real issue - because they hold
very little data outside the data models. I would investigate to see if
multiple copies of the data models are being generated. If not, then
maybe the delegators aren't to blame.
Another thing to check is classes that hold references to delegator
objects instead of delegator names. There was some recent work to fix
those occurrences - maybe some areas were missed.
-Adrian
On 4/4/2012 5:24 PM, Justin wrote:
One of my main aims has been to detach the services triggered by ant
targets on start up, in order to reduce the need to do server restarts on
the mt system for obvious reasons.
Now that I'm load testing I've discovered that the fact that the container
bound services to create/initialize new tenant
were tied to start up, hid memory issues.
To solve the "Exception in thread "RMI TCP Connection(idle)"
java.lang.OutOfMemoryError: Java heap space occurred." which tends to occur
when initializing (building db& loading the data) the 4th tenant I've been
looking for ways to insure that no references to delegators no longer in
active use exist thereby making GC possible& freeing up memory.
Alternatively I thought to look at classes who's state with specific regard
to the associated delegator is not important& maybe implementing a means
for such to be shared between delegators.
I've been looking at JobManager, JobPoller.destroyThreadPool(),
ServiceDispatcher, DispatchContext& the classloader to try come up with at
strategy of how memory with regards to delegators may be better managed.
I'm a bit overwhelmed at the moment& thought I might ask on the forum if
anyone has had any experience with this sort of thing before ... I've often
picked up a clue that helped me keep going here.
Thanks very much for your time.
Regards,
Justin
