Bugzilla – Bug 856
thread leak with gram CallbackHandler
Last modified: 2005-12-05 16:47:39
You need to
before you can comment on or make changes to this bug.
When using the gram APIs, a BaseServer class/thread is created and started to
handle any callbacks. But, the way I'm using the cog library,
BaseServer.shutdown() is never called so this thread hangs around forever.
I'm not sure what the appropriate fix is. One thing I do know is that Gram
deactivation (where handler.shutdown() is called) isn't being performed the way
I'm using the java cog. I'm using the gram client in my own server that doesn't
ever stop running, so the deactivation is never called. Plus, each connection to
my server sends a new proxy so I'll have 1 (proxy,handler) entry in the
callbackHandlers cache for each connection made to my server. The server gets
100s or 1000s of connections over time and it's running out of threads and memory.
I glanced at the 1.1a code, and this problem seems to be in there as well.
We can add a call that returns a handler for a given proxy and then you would
have to call shutdown() on it or we can add a deactivateHandler() call that
will call shutdown() for you for a given proxy.
I actually hacked up the CoG to add something similar to the
you suggest. I ended up thinking it was too much of a hack. I instead have the
CoG use 1 handler per user. If a new proxy is presented for a user that is too
much newer than the existing one (I think I picked 2 hours), I shutdown the
handler with the old proxy, and created a new handler on the same port with the
new proxy. There are some problems with this approach, obviously.
I'm not sure how much longer this code will be used, but you might want to
consider refactoring the whole thing. My first thought (and I didn't think
it for very long) is to change things around so that a Gram is the main service
object that has a proxy associated with it (I think this is what Gregor argued
for way back when :-). In other words make it look more like a service oriented
architecture, with the Gram being the service. So, you'd do something like:
Gram gram = new Gram(url,proxy);
GramJob job = new GramJob();
job.addListener(this); // the gram object would actually do the listening
// yadda yadda
gram.shutdown(); // or maybe gram.disconnect()?
This changes things so listening is per-gram and exposes a required shutdown to
the user. I think it would also get rid of the static methods and variables in
the Gram class and the duplicate calls between the Gram and GramJob classes.
We can change the proxy-handler mapping to be proxy identity-handler mapping.
That way, you would have 1 handler per user then per proxy instance. But then
you still wouldn't be able to access the handlers.. so maybe a best option is
to define deactivateHandler() call and change the mapping to be credential
Since the whole world is switching to the OGSI interfaces it's probably not
worth changing the GRAM CoG API now. It soon will be obsolete.
Added Gram.deactivateCallbackHandler(GSSCredential) function. The credential-
handler mapping was unchanged.