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.
See also this old thread:
https://groups.google.com/forum/#!topic/jclouds/pF9ZqXPdLTk
Regards
ap
?As far as I know this fix should have been in 1.9.0, so I'm surprised it's not.
From: Forrest Townsend
Sent: Wednesday, May 6, 2015 6:32 PM
To: user@jclouds.apache.org
Subject: COMMERCIAL:Re: Openstack keystone swift token expiration
I have already voted for th
I have already voted for this bug report haha :)
Thank you for your comments! Unfortunately I am not in a situation right
not to run with 2.0.0, but if I have some down time I will try and comment
back on https://issues.apache.org/jira/browse/JCLOUDS-615.
Thanks,
Forrest T.
On Wed, May 6, 2015
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 secon
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 p
Hi Forrest,
If I'm not wrong you're hitting
https://issues.apache.org/jira/browse/JCLOUDS-615.
If that is the case, there is a comment indicating that is fixed in
2.0.0-SNAPSHOT. Could you confirm that? Let's help us test this and
add you feedback (and vote) to the issue.
HTH!
I.
On 6 May 2015
Hi
I am running with jclouds version 1.8 and was curious if any other people
have been hitting the default 60 minute token expiration. If someone has
experienced this, what is a known work around? I know this isn't an
openstack email list but but if you [1] issue a new connection to openstack
thro
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 co
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
On May6 10:57 AM,
Hi Ignasi,
I've attached the test code, including the quick&dirty thread set
comparisons. You can strip that out and just watch the threads via
jconsole or some other monitoring app if you prefer.
Thanks,
--Ryan
On May6 3:44 AM, Ignasi Barrera wrote:
Hi Ryan,
Can you share the complete
Hi Ryan,
Can you share the complete test code, including how you create the jclouds
context and the loop you're using, so I can run it to reproduce the issue?
Thanks!
I.
El 05/05/2015 21:11, "Ryan Shoemaker"
escribió:
> Hi,
>
> I'm running jclouds 1.8.0 with Guava 17.0 and I'm seeing threads
11 matches
Mail list logo
