Awesome, thanks!
Does the "jclouds.user-threads" property control the thread pool per
context or across all contexts? Are the threads always created when the
context is created or does it depend on what you do with the context?
For example, our app calls CSC. getNodeMetadata() all over the place,
but never closes the CSC. I haven't tested, but I don't think this
causes the thread lingering issue we see when creating an SshClient.
As I mentioned above, our application relies heavily on CSC for
gathering node meta data and for creating ssh sessions. We have 60+
usages where we call our own utility method
getComputeServiceContext(...) which builds the context like I showed in
my sample code. Most of the time as a side-effect of some other
operation, like creating an SshClient. So it isn't easy for the calling
code to close the context when it's done with the SshClient (because it
was created locally within the util method). I need to refactor that to
work differently unless the user-threads prop gives me an easy way out.
I'm trying to weigh the options...
Thanks again,
--Ryan
On May6 5:38 PM, Ignasi Barrera wrote:
That is the most common reason threads remain there forever. When the
jclouds context is created, two ExecutorServices are created: an I/O
executor that runHTTP stuff, and a "user executor" that runs other
concurrent tasks. Both executors need to be shut down, and that
happens when you close the context.
Apart from that, you might want to configure the
"jclouds.user-threads" when creating the context. It is set to 0 by
default and that creates an unbounded cached thread pool [2], so
threads might be created and remain there for some time. You set a
custom value for that property in order to have more control on the
size of the thread pool.
HTH!
I.
[1]
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/Constants.java#L26-L31
[2]
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool()
On 6 May 2015 at 23:17, Ryan Shoemaker <ryan.shoema...@enterprisedb.com> wrote:
Hi Ignasi,
It looks like a simple issue of not closing the ComputeServiceContext. When
I added that, all of the background threads seem to exit nicely. Now I just
have to mop up the 60+ places in our code where the contexts are created and
never closed...
Thanks,
--Ryan
