Threads are not created by default. They are created as needed and placed in the executor's thread pool (which size is controlled by the "jclouds.user-threads" property) and remain in there to be reused when possible. They are terminated and removed from the pool when they've been idle for 60 seconds.
Creating and destroying the context is a quite complex operation. That builds the dependency injection object graph, instantiates and injects the singletons, creates the executors (each context has its own executors; there is no static shared state, everything in jclouds is context-scoped) etc, so in general, I'd say you try to create a context just once and reuse it when possible, and configure the thread pool size to fit your app needs. On 7 May 2015 at 00:15, Ryan Shoemaker <[email protected]> wrote: > 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 <[email protected]> > 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 > > >
