SimpleDB with custom port numbers and max retries issue

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Download and install http://code.google.com/p/simpledb-dev/
2. Launch simpledb-dev (NB: defaults to port 8080)
3. Run:

SimpleDB simpleDb = new SimpleDB("x", "x", false, "localhost", 8080);
simpleDb.setMaxRetries(0);
System.out.println("DB max retries: " + simpleDb.getMaxRetries());
Domain d = simpleDb.createDomain("issue_report");
System.out.println("Domain max retries: " + d.getMaxRetries());
QueryResult result = d.listItems();
System.out.println("Result box use: " + result.getBoxUsage());

What is the expected output? What do you see instead?

Expected:

DB max retries: 0
Domain max retries: 0
Result box use: 0.0000219907

Received:

DB max retries: 0
Domain max retries: 5
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request
I/O exception (java.net.ConnectException) caught when processing request:
Connection refused
Retrying request

There are two issues: (a) Typica does not observe port 8080 in the created
Domain (nor any other object subsequently created by Domain); and (b) the
setMaxRetries(0) is being ignored in the created Domain.

It is possible to use port 80 instead of 8080 with simpledb-dev. This works
around issue (a) and suggests simpledb-dev is working correctly.
Simpledev-dev port 8080 usage was tested successfully using
http://code.google.com/p/amazon-simpledb-cli/.

What version of the product are you using? On what operating system?

Typica 1.5; Ubuntu 8.10 (2.6.27-11-generic i686); Java 1.6.0_10.

Original issue reported on code.google.com by ben.a...@gmail.com on 14 Feb 2009 at 1:33

[GoogleCodeExporter]

I've addressed the port # in svn r276. Going to look at the max retries now

David

Original comment by dkavan...@gmail.com on 16 Aug 2009 at 1:37

• Changed state: Started

[GoogleCodeExporter]

Along with max retries, there are a number of other connection related 
properties that need to be set on the 
domain. I need to think of a better strategy for managing these.

Original comment by dkavan...@gmail.com on 16 Aug 2009 at 1:39

[GoogleCodeExporter]

Short term, set them on the domain. I'm going to put some code into 
AWSQueryConnection that copies all 
connection properties from the current one to the one passed in. This will be 
called internally in typica, so you 
won't have this problem after the next release.

Original comment by dkavan...@gmail.com on 7 Oct 2009 at 1:30

[GoogleCodeExporter]

Got back to looking at this code this afternoon and what I have implemented in 
the SimpleDB.createDomain and 
getDomain calls should preserve all of the properties on the SimpleDB object. 
Have you tried a more recent 
release?

Original comment by dkavan...@gmail.com on 7 Oct 2009 at 7:01

[GoogleCodeExporter]

How about making a release so we can use the port fix?

Original comment by stephen....@gmail.com on 28 Jan 2010 at 11:29

[GoogleCodeExporter]

The new code looks good - it basically just reuses the HttpClient, which will 
carry over timeout settings and 
maxclient settings. I think all we need to do now is release :)

Original comment by pligh...@gmail.com on 24 Feb 2010 at 9:16

[GoogleCodeExporter]

We tried out a trunk build and there are still port settings not being passed 
around 
correctly--see sdb.Item, sqs.MessageQueue, and sqs2.MessageQueue all still 
doing the 
"port = isSecure ? 443 : 80" logic instead of accepting a port constructor 
parameter.

Having all these classes extend AWSQueryConnection seems like an abuse of 
inheritance--it'd be cleaner to just pass in the one AWSQueryConnection 
instance 
instead of having each new child re-initialize the same data each time. I guess 
unless changing ports/etc. on a per-child instance basis is a 
purposefully-supported 
use case.

Original comment by stephen%...@gtempaccount.com on 25 Feb 2010 at 5:45

[GoogleCodeExporter]

I should probably use the delegation model. I was trying to allow the user 
access to 
those connection properties directly. Probably should have just made them get 
the 
connection delegate and molest that directly. Hmm, typica 2.0?? maybe a switch 
to JibX 
at the same time, and my SimpleDB re-think.. might be time for all of the above.

Original comment by dkavan...@gmail.com on 24 Mar 2010 at 3:59

[GoogleCodeExporter]

I've attached a diff of more port fixes in our 1.6 fork, rebased against the 
latest 
head. It'd be great to get these into 1.7.

Original comment by stephen....@gmail.com on 25 Mar 2010 at 6:09

Attachments:

• port-fixes.diff

[GoogleCodeExporter]

I know it's been a long time, but I finally got this patch applied and it's in 
SVN r335

Original comment by dkavan...@gmail.com on 8 Jul 2010 at 9:03

• Changed state: Fixed