Unsolved
This post is more than 5 years old
2 Posts
0
1592
Problem uploading large files (>2G) with JClouds
I tried code based on jclouds example for large blobs and get: java.util.concurrent.ExecutionException" java.lang.reflect.UndeclaredThrowableException
That code works on smaller files.
Also modified the code above to use Inputstream (in place of File object) and get error like: contentLength must be set, streaming not supported
That code does not work on small or large files.
I have working code on smaller files using byte[] interfaces.
Jclouds and atmos version 1.5.3, Linux, JDK 1.6.x
Thanks for any help
JasonCwik
281 Posts
0
June 20th, 2013 12:00
EMC does not develop the JClouds API, so I don't have an exact answer for you. Can you include the entire stack trace? It sounds like you may be mixing incompatible libraries.
For streaming an upload, the length of an InputStream is required up-front since the HTTP protocol needs to know the request size. The JClouds adapter for S3 has the same requirement. The error about contentLength is thrown here:
GrepCode: org.jclouds.atmos.binders.BindMetadataToHeaders (.java) - Class - Source Code View
It appears that it's looking for the content length from the object metadata. Perhaps there's some way to set this value before attempting to stream the request?
javastarchild
2 Posts
0
June 20th, 2013 17:00
Thanks. That made it work better! Streaming now works on small files but fails with different error on large files. I don't have a complete stack trace just and few error messages:
1.
http.handlers.BackoffLimitedRetryHandler - Cannot retry after server error, command is not replayable: [method=AtmosAsyncClient.createFile, request=POST ....
2.
........ java.util.concurrent.ExecutionException: org.jclouds.http.HttpResponseException: Error .....
Thanks again.
JasonCwik
281 Posts
0
June 21st, 2013 09:00
Unfortunately, it's going to be hard to figure anything out without the full error messages and stack traces.
#1 is expected since you usually can't replay a request streamed with an InputStream.
One way to debug this is to set up a proxy like Charles Proxy or Fiddler. Then you can direct traffic through the proxy and watch the HTTP operations directly.