Now Getting Strange Error

61 views
Skip to first unread message

jared

unread,
Dec 11, 2012, 8:22:54 PM12/11/12
to jcl...@googlegroups.com
First of all, I'm basically using the compute-basics example with EC2. It's been working well. However, I've started getting what seems like a strange error to me. Hopefully someone knows why I'm getting this error.

Here is the stack trace:

error: null
Exception in thread "user thread 1" java.lang.IllegalStateException: interrupted calling get() on [[method=AvailabilityZoneAndRegionAsyncClient.describeAvailabilityZonesInRegion, request=POST https://ec2.sa-east-1.amazonaws.com/ HTTP/1.1]], so could not run listeners
at org.jclouds.concurrent.Futures$CallGetAndRunExecutionList.run(Futures.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:979)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.jclouds.concurrent.config.DescribedFuture.get(DescribedFuture.java:45)
at org.jclouds.concurrent.Futures$CallGetAndRunExecutionList.run(Futures.java:59)
... 3 more

I saw on an old post that this may be associated with some kind of timeout. Would that make sense? If so, how do I change it? The availability zone section confuses me. It appears to be attempting sa-east-1 (South America?). That's not at all the region I specified in the template builder. Any insights would be appreciated.

Thanks,
Jared

Adrian Cole

unread,
Dec 11, 2012, 10:26:19 PM12/11/12
to jcl...@googlegroups.com

Hey, Jared.

Sometimes this happens when a context is closed while a command is still running.  It looks like the call is to Sao Paolo.  Maybe you can consider constricting the regions jclouds connects to via setting the property jclouds.regions to a comma-separated list of the regions you use.

-A

--
You received this message because you are subscribed to the Google Groups "jclouds" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jclouds/-/lwR_Q2MbfRMJ.
To post to this group, send email to jcl...@googlegroups.com.
To unsubscribe from this group, send email to jclouds+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jclouds?hl=en.

Rob Ryan

unread,
Dec 12, 2012, 11:29:14 AM12/12/12
to jcl...@googlegroups.com
Yesterday Sao Paolo had an outage, and our JClouds calls not even involving Sao Paolo failed with the error below.

The jclouds.regions setting is starting to sound like a necessity to limit exposure to failure modes in JClouds triggered by problems in regions not even being used...

Is there a document somewhere which describes any configuration/API usage practices should be followed to achieve maximum reliability?

This is the second time Sao Paolo has given our system problems. When Sao Paolo first came online we got an NPE within JClouds (patch already submitted for that), and now when it went down JClouds failed operations not involving Sao Paolo.

-Rob

Adrian Cole

unread,
Dec 12, 2012, 11:46:44 AM12/12/12
to jcl...@googlegroups.com
Hi, Rob.

http://www.jclouds.org/documentation/userguide/using-ec2/ doesn't have
this info...

but feel free to help annotate your findings via the "edit" button.
https://github.com/jclouds/jclouds.github.com/blob/master/documentation/userguide/using-ec2.md

The very best practice now, is to isolate jclouds to only use the
regions, and owners you use. You can use ContextBuilder.overrides to
add the following:

jclouds.regions=us-east-1,eu-west-1,... << white list your regions
jclouds.ec2.cc-regions=us-east-1,eu-west-1... << if you don't use
cluster instances, set this to ""
jclouds.ec2.ami-query=owner-id=137112412989,801119661308,063491364108,099720109477,411009282317;state=available;image-type=machine
<< remove owner ids you use. if you only use explicit ids (ex.
template.imageId()) then set this to ""

Using the above will reduce your network calls! In the jclouds-dev
group, we are also actively investigating how to integrate with
hystrix to help with availability issues like you mention.
https://groups.google.com/forum/?fromgroups=#!topic/jclouds-dev/fVILfUoW_zg

HTH
-A

On Wed, Dec 12, 2012 at 8:29 AM, Rob Ryan <ebore...@gmail.com> wrote:
> jclouds.regions

Adrian Cole

unread,
Dec 12, 2012, 11:47:07 AM12/12/12
to jcl...@googlegroups.com
s/remove owner ids you use/remove owner ids you don't use/ :)

On Wed, Dec 12, 2012 at 8:46 AM, Adrian Cole <adrian...@gmail.com> wrote:
> remove owner ids you use

jared

unread,
Dec 12, 2012, 12:25:11 PM12/12/12
to jcl...@googlegroups.com
OK. Sweet! I'll do this.

Jared
Reply all
Reply to author
Forward
0 new messages