google-code-export / typica

Automatically exported from code.google.com/p/typica
Apache License 2.0
1 stars 1 forks source link

Infinite Loop in AttrWorker.java line 47 #30

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Attempt to get data out of a SDB Domain that does not exist.
2. AttrWorker.java line 47 will enter an infinite loop.  Since the Domain
doesn't exist, an exception is thrown, then eaten, but there's no break
statement (or at least the 'done' boolean doesn't get set).

What is the expected output? What do you see instead?
The program should continue on normally.  Instead, I see the following in
the console:
2008-09-18 15:11:51,565 ERROR [STDERR] some sdb error, retrying...
Client error : The specified domain does not exist.
2008-09-18 15:11:51,729 ERROR [STDERR] some sdb error, retrying...
Client error : The specified domain does not exist.
2008-09-18 15:11:51,856 ERROR [STDERR] some sdb error, retrying...
Client error : The specified domain does not exist.
2008-09-18 15:11:52,012 ERROR [STDERR] some sdb error, retrying...
Client error : The specified domain does not exist.

What version of the product are you using? On what operating system?
Java 6, Typica Head, Windows Vista 64

Please provide any additional information below.
This problem could arise if any SDBError gets thrown here, not just a
non-existent Domain.

Original issue reported on code.google.com by sappenin on 13 Oct 2008 at 10:19

GoogleCodeExporter commented 9 years ago
BTW, I'm working on this (in between other stuff). I need to use Callable, 
instead of
Runnable in the AttrWorker, so exceptions can be passed back.

Original comment by dkavan...@gmail.com on 5 Nov 2008 at 4:00

GoogleCodeExporter commented 9 years ago
In the meantime, you should add a "break;" statement inside of the catch to 
prevent
an infinite loop (outside of the if statement)

catch (SDBException sdbex) 
{
  AWSError err = sdbex.getErrors().get(0);
  if (err.getCode().equals("NoSuchDomain")) 
  {
  //throw sdbex;
  }
  break;
}

Original comment by sappenin on 8 Jan 2009 at 2:35

GoogleCodeExporter commented 9 years ago
Any update on this one?  Could you at least add the break; statement until you 
can 
get the exception passing fixed?

Original comment by sappenin on 29 Jan 2009 at 8:35

GoogleCodeExporter commented 9 years ago
I'm trying to fix this one, finally. To reproduce, I'm calling 
listItemsAttributes and that fails fast in the listItems 
call within. I'm going to test with getItemsAttributes, because I suspect that 
would cause it. Though, I'm 
having a hard time figuring out how you get this to fail. Assume you have a 
Domain object (which might not 
be valid if the domain doesn't exist), and you want a list of item ids to 
retrieve, so you run a query.. well, that 
will fail since the domain doesn't exist. 
I thought more about putting the break or return into AttrWorker. All that does 
is cause the worker to exit, but 
doesn't stop the main loop in the Domain code from threading of more workers, 
no? I suppose it won't be 
endless since it will simply exhaust the list of item identifiers. I'd prefer 
to throw an exception to make it fail 
fast, but since I haven't had much time to work on this, I'll at least get a 
return in there to cause the 
AttrWorker to abort this call.

Original comment by dkavan...@gmail.com on 3 Feb 2009 at 2:35

GoogleCodeExporter commented 9 years ago

Original comment by dkavan...@gmail.com on 3 Feb 2009 at 2:36

GoogleCodeExporter commented 9 years ago
Yeah, this error only occurs if the Domain has not yet been created in AWS.  
This is
probably a rare case, but I ran into it while testing a new project, so I 
suppose the
"Domain doesn't exist" condition might occur whenever a new project is run, but
pre-initialization.

Your fix makes sense to me, although it still feels a bit dangerous.  If some 
other
exception is thrown where the errorCode does not contain "NoSuchDomain", then 
the
while loop will continue, likely infinitely.  For now, though, this satisfies my
error (but we should probably think more about this issue -- you may not want 
to mark
this as "fixed" just yet).

Original comment by sappenin on 3 Feb 2009 at 6:48