Can jets3t be used to connect to EMC ATMOS devices?

35 views
Skip to first unread message

mmr1...@gmail.com

unread,
Nov 3, 2016, 7:11:43 AM11/3/16
to JetS3t Users

I have an app that interfaces with different cloud storage devices. It uses S3 and jets3t-0.6.1.jar to talk to Amazon. Using the same interface I like to talk to ATMOS but no matter what properties I set for the org.jets3t.service.impl.rest.httpclient.RestS3Service, it always goes to s3.amazonaws.com instead of the ATMOS host that I have specified. The logs collected show that the two paths taken are different:

 

Amazon which works:

org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:334)          "Performing PUT request for 'https://MYBUCKET.s3.amazonaws.com/8e3c3d97-0c2f-42bb-aee7-2b1674bb439b', expecting response code 200"

 

ATMOS:

org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:334)          "Performing PUT request for 'https://s3.amazonaws.com/CASBucket/ba9ec436-f467-402f-9b51-dbf490260cca', expecting response code 200"

 

Right before issuing the “myRestS3Service.putObject(bucket, s3obj);” I print all the properties of myRestS3Service and they are what I expect (i.e. my ATMOS host and port are there and no reference to s3.amazonaws.com).

 

I have experimented with a variety of combinations of these properties:

 

                    httpclient.proxy-autodetect=true;

                    httpclient.proxy-host=HOST;

                    httpclient.proxy-port=PORT;

                    s3service.s3-endpoint=HOST;

                    s3service.s3-endpoint-http-port=PORT;

                    s3service.s3-endpoint-https-port=PORT;

                    s3service.disable-dns-buckets=false;

                    s3service.https-only=true;

 

Has anyone had success with jets3t with ATMOS?

James Murty

unread,
Nov 3, 2016, 7:33:31 AM11/3/16
to jets3t...@googlegroups.com
Hi,

The 0.6.1 release of JetS3t is more than 8 years old now, you should consider updating to the latest version (which is still over a year old) if you can.

That said, the problem you are facing is probably because in 0.6.1 the "s3service.s3-endpoint" property is initialised as `org.jets3t.service.Constants#S3_HOSTNAME` when the Constants class is first loaded. If the "s3service.s3-endpoint" property is not set in a jets3t.properties file when your app starts, no subsequent changes to this property will have any effect.

You can work around the issue by setting Constants#S3_HOSTNAME directly to your ATMOS hostname, though of course this applies globally to the app and any services running in the JVM.

Later versions of JetS3t do not have this problem, and support service-specific and dynamic updates for "s3service.s3-endpoint" settings.

Hope this helps,
James




--
You received this message because you are subscribed to the Google Groups "JetS3t Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jets3t-users+unsubscribe@googlegroups.com.
To post to this group, send email to jets3t...@googlegroups.com.
Visit this group at https://groups.google.com/group/jets3t-users.
For more options, visit https://groups.google.com/d/optout.

mmr11408

unread,
Nov 3, 2016, 10:49:49 AM11/3/16
to JetS3t Users
Thanks. Upgrading to 0.9.4 resolved the issue. The upgrade now requires java-xmlbuilder-1.1.jar which has classes such as: com/jamesmurty/utils/BaseXMLBuilder.class

Any chance of that changing to something that is more open source like (say "org.jets3t") ? Or eliminating that dependency?

James Murty

unread,
Nov 4, 2016, 8:39:52 AM11/4/16
to jets3t...@googlegroups.com
Hi,

I'm glad upgrading solved the problem.

You don't need to worry about java-xmlbuilder, that project is just as open source as JetS3t since it is licensed as Apache 2. Here is the project home: https://github.com/jmurty/java-xmlbuilder

Like Jets3t, I wrote it. It actually started life inside JetS3t but I moved it into a separate library because it is more broadly useful.

Regards,
James


--

mmr11408

unread,
Nov 7, 2016, 1:43:42 PM11/7/16
to JetS3t Users
Thanks James. Testing EMC ATMOS performance via their REST and S3 API shows a significant difference with S3 being at least 3 times slower than the REST API. Appending to their community they suggested:
  • definitely check that you have HTTP keep-alive enabled on the server and client.

No keep-alive related property is documented here: http://jets3t.s3.amazonaws.com/toolkit/configuration.html

I tried a few different combinations (e.g. "httpclient.keep-alive", "timeout=60000,max=100") with no avail. Are you aware of a way to set that on the client side?
Reply all
Reply to author
Forward
0 new messages