Re: S3 multipart upload throws NPE occasionally
I just realized the problem is probably due to the fact that HTML is
generally case insensitive and the regex expects the HMTL tag to be exactly
. It's much easier (for me) to imagine the match failed because
they used an HTML tag with a different case than to imagine they embedded a
space in the id string.
The simplest fix then would be:
Pattern pattern =
Pattern.compile("(?i)([\\S&&[^<]]+)");
The addition of the (?i) at the front would allow the entire regex to match
all explicit characters in a case-insensitive manner. I've tested this with
a Java regex tester and it works.
I'll compile and test this myself. I'll let you know if it seems to fix the
issue.
John
On Tue, Sep 14, 2021 at 4:52 PM John Calcote wrote:
> Hi Andrew,
>
> Thanks for the quick response, but I don't think there's anything wrong
> with that regex. The expression - "([\\S&&[^<]]+)" -
> is pretty simple once you understand what the double ampersand does - it's
> an intersection operator. This regex means: Match the string
> X where X can be any list of non-whitespace characters
> (\\S) except the '<' character (which, of course, allows the expression to
> pick up all the non-whitespace characters between the opening tag and the
> start of the closing tag or the first whitespace character). The parens
> around X in the expression indicate a group, so it can be extracted from
> the results. If there ARE any whitespace characters between the opening and
> closing html tags, the expression will not match because the first
> character after the capture group is expected to be a '<' character.
>
> The system to which we're trying to upload is a t-systems OTC (Open
> Telecom Cloud) S3 service. We've heard OTC is based on Huawei Object
> Storage. It's possible it's not a perfect S3 implementation and this is the
> first time we've tried to hit it with a multi-part upload. It's possible
> the S3 service is sending an UploadId with an embedded whitespace
> character, which would cause the match to fail, and the capture group to
> return null. Although it seems stupid to do so, I don't see anything in the
> Amazon spec about not using whitespace in the upload id. To make a space
> work properly, you'd have to URL-encode the uploadId when using it in
> subsequent PUT request parameters.
>
> Further thoughts?
>
> John
>
> On Thu, Sep 9, 2021 at 5:15 PM Andrew Gaul wrote:
>
>> On Thu, Sep 09, 2021 at 07:37:49PM -, John Calcote wrote:
>> > java.lang.NullPointerException: Null id
>> > at
>> org.jclouds.blobstore.domain.AutoValue_MultipartUpload.(AutoValue_MultipartUpload.java:32)
>> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
>> > at
>> org.jclouds.blobstore.domain.MultipartUpload.create(MultipartUpload.java:35)
>> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
>> > at
>> org.jclouds.s3.blobstore.S3BlobStore.initiateMultipartUpload(S3BlobStore.java:371)
>> ~[s3-2.3.0.jar:2.3.0]
>> > at
>> org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:356)
>> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
>> > at
>> org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:349)
>> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
>> > at
>> org.jclouds.s3.blobstore.S3BlobStore.putBlob(S3BlobStore.java:262)
>> ~[s3-2.3.0.jar:2.3.0]
>>
>> UploadIdFromHttpResponseViaRegex has a suspicious regular expression:
>>
>> Pattern.compile("([\\S&&[^<]]+)")
>>
>> Do you use AWS or another S3 object store? I suspect that this regex
>> fails to match in some corner case. Could you simplify it and submit a
>> GitHub PR?
>>
>> --
>> Andrew Gaul
>> http://gaul.org/
>>
>
Re: S3 multipart upload throws NPE occasionally
On Thu, Sep 09, 2021 at 07:37:49PM -, John Calcote wrote:
> java.lang.NullPointerException: Null id
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartUpload.(AutoValue_MultipartUpload.java:32)
> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
> at
> org.jclouds.blobstore.domain.MultipartUpload.create(MultipartUpload.java:35)
> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
> at
> org.jclouds.s3.blobstore.S3BlobStore.initiateMultipartUpload(S3BlobStore.java:371)
> ~[s3-2.3.0.jar:2.3.0]
> at
> org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:356)
> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
> at
> org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:349)
> ~[jclouds-blobstore-2.3.0.jar:2.3.0]
> at org.jclouds.s3.blobstore.S3BlobStore.putBlob(S3BlobStore.java:262)
> ~[s3-2.3.0.jar:2.3.0]
UploadIdFromHttpResponseViaRegex has a suspicious regular expression:
Pattern.compile("([\\S&&[^<]]+)")
Do you use AWS or another S3 object store? I suspect that this regex
fails to match in some corner case. Could you simplify it and submit a
GitHub PR?
--
Andrew Gaul
http://gaul.org/
S3 multipart upload throws NPE occasionally
Hi Andrew,
I'm running jclouds 2.3.0 these days. Here's the call stack:
java.lang.NullPointerException: Null id
at
org.jclouds.blobstore.domain.AutoValue_MultipartUpload.(AutoValue_MultipartUpload.java:32)
~[jclouds-blobstore-2.3.0.jar:2.3.0]
at
org.jclouds.blobstore.domain.MultipartUpload.create(MultipartUpload.java:35)
~[jclouds-blobstore-2.3.0.jar:2.3.0]
at
org.jclouds.s3.blobstore.S3BlobStore.initiateMultipartUpload(S3BlobStore.java:371)
~[s3-2.3.0.jar:2.3.0]
at
org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:356)
~[jclouds-blobstore-2.3.0.jar:2.3.0]
at
org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:349)
~[jclouds-blobstore-2.3.0.jar:2.3.0]
at org.jclouds.s3.blobstore.S3BlobStore.putBlob(S3BlobStore.java:262)
~[s3-2.3.0.jar:2.3.0]
My code calls S3BlobStore.putBlob as follows:
blobStore.putBlob(cspInfo.getContainer(), blob,
multipart());
blob is defined as:
Blob blob = blobStore.blobBuilder(key)
.payload(content)
.contentDisposition(key)
.contentLength(meta.getContentLength())
.contentMD5(HashCode.fromBytes(meta.getChecksum()))
.contentType(MediaType.APPLICATION_OCTET_STREAM)
.userMetadata(meta.getUserMeta())
.build();
When it happens (not very often), the problem seems to be here (in
S3BlobStore.java):
@Override
public MultipartUpload initiateMultipartUpload(String container,
BlobMetadata blobMetadata, PutOptions overrides) {
PutObjectOptions options = new PutObjectOptions();
if (overrides.getBlobAccess() == BlobAccess.PUBLIC_READ) {
options = options.withAcl(CannedAccessPolicy.PUBLIC_READ);
}
String id = sync.initiateMultipartUpload(container,
blob2ObjectMetadata.apply(blobMetadata), options);
return MultipartUpload.create(container, blobMetadata.getName(), id,
blobMetadata, overrides);
}
In the last two lines 'id' is returned by the S3Client (sync) during the
initiateMultipartUpload call. But id is occasionally returned as null for some
reason. To be fair, I've only seen this happen once. I tried to chase it
further, but (to be completely honest), I do not (nor have I ever been able to)
figure out how to get past the S3Client barrier in jclouds. That is, I'm not
very good with guice, so I don't know how to follow the code properly past a
guice binding interface like S3Client.
Re: Swift Multipart upload SLO or DLO
Sorry I cannot help you debug your Swift configuration. jclouds SLO
works with properly configured public providers like Rackspace so I
suggest exploring the differences between it and your local setup.
jclouds 2.0.0 does not support DLO and the older jclouds 1.9.1 Swift
implementation works differently so I do not recommend using it. I did
not mention a test case and do not understand your last comment.
On Wed, Apr 05, 2017 at 10:20:15AM +, Archana C wrote:
> Hi
>
> 1. Do you enable "SLO" in swift as required filter (swift/proxy/server.py)
> required_filters = [
> {'name': 'catch_errors'},
> {'name': 'gatekeeper',
> 'after_fn': lambda pipe: (['catch_errors']
> if pipe.startswith('catch_errors')
> else [])},
> {'name': 'dlo', 'after_fn': lambda _junk: [
> 'staticweb', 'tempauth', 'keystoneauth',
> 'catch_errors', 'gatekeeper', 'proxy_logging']}]
> Should this be slo for static large object upload ? Or is there any thing to
> be done to treat request as SLO.
>
> 2. I noticed that "DLO" is enabled as a default filter (confirmed from swift
> logs), hence adding header "X-Object-Manifest" only helped get correct
> Content-length.
> 3. I compared 1.9.1 jcloluds CommonSwiftClient.java:putObjectManifest with
> jclouds 2.0 StaticLargeObject.java:replaceManifest, I figured out that
> "X-Object-Manifest" is used as required in jclouds 1.9.1 and that has been
> omitted in 2.0
> Please share sample test case that you mentioned
> RegardsArchana
>
> On Wednesday, 5 April 2017, 15:49, Archana C
> wrote:
>
>
> Hi
>
> 1. Do you enable "SLO" in swift as required filter (swift/proxy/server.py)
> required_filters = [
> {'name': 'catch_errors'},
> {'name': 'gatekeeper',
> 'after_fn': lambda pipe: (['catch_errors']
> if pipe.startswith('catch_errors')
> else [])},
> {'name': 'dlo', 'after_fn': lambda _junk: [
> 'staticweb', 'tempauth', 'keystoneauth',
> 'catch_errors', 'gatekeeper', 'proxy_logging']}]
> Should this be slo for static large object upload ? Or is there any thing to
> be done to treat request as SLO.
>
> 2. I noticed that "DLO" is enabled as a default filter (confirmed from swift
> logs), hence adding header "X-Object-Manifest" only helped get correct
> Content-length.
> 3. I compared 1.9.1 jcloluds CommonSwiftClient.java:putObjectManifest with
> jclouds 2.0 StaticLargeObject.java:replaceManifest, I figured out that
> "X-Object-Manifest" is used as required in jclouds 1.9.1 and that has been
> omitted in 2.0
> Please share sample test case that you mentioned
> RegardsArchana
>
> On Tuesday, 4 April 2017, 23:39, Andrew Gaul wrote:
>
>
> jclouds supports static large objects with Swift. We could add support
> for dynamic objects but these have a number of caveats and differ from
> other providers.
>
> On Tue, Apr 04, 2017 at 04:28:56PM +, Archana C wrote:
> > Hi
> >
> > Does jclouds 2.0.0 supports swift Static Large Object Upload (SLO) or
> > Dynamic Large Object Upload(DLO) ?
> >
> > As per our observation,
> > 1. It looks like jClouds does SLO and not DLO.
> > 2. SLO requires no headers whereas DLO requires X-Object-Manifest as header
> > while manifest upload as mentioned in [1].
> >
> > [1]
> > https://docs.openstack.org/user-guide/cli-swift-large-object-creation.html
> > RegardsArchana
> >
>
> --
> Andrew Gaul
> http://gaul.org/
>
>
>
>
>
--
Andrew Gaul
http://gaul.org/
Re: Swift Multipart upload SLO or DLO
jclouds supports static large objects with Swift. We could add support for dynamic objects but these have a number of caveats and differ from other providers. On Tue, Apr 04, 2017 at 04:28:56PM +, Archana C wrote: > Hi > > Does jclouds 2.0.0 supports swift Static Large Object Upload (SLO) or Dynamic > Large Object Upload(DLO) ? > > As per our observation, > 1. It looks like jClouds does SLO and not DLO. > 2. SLO requires no headers whereas DLO requires X-Object-Manifest as header > while manifest upload as mentioned in [1]. > > [1] https://docs.openstack.org/user-guide/cli-swift-large-object-creation.html > RegardsArchana > -- Andrew Gaul http://gaul.org/
Swift Multipart upload SLO or DLO
Hi Does jclouds 2.0.0 supports swift Static Large Object Upload (SLO) or Dynamic Large Object Upload(DLO) ? As per our observation, 1. It looks like jClouds does SLO and not DLO. 2. SLO requires no headers whereas DLO requires X-Object-Manifest as header while manifest upload as mentioned in [1]. [1] https://docs.openstack.org/user-guide/cli-swift-large-object-creation.html RegardsArchana
Re: MultiPart Upload
You can control the number of threads, but I think the minimum and maximum part size and the maximum number of parts is controlled by the specific jclouds provider. -Zack From: Archana C <carchan...@yahoo.co.uk> Sent: Wednesday, February 8, 2017 6:18 AM To: user@jclouds.apache.org Subject: MultiPart Upload Hi Is there a way to substitute attributes in MultipartUploadSlicingAlgorithm (min, max and number of parts) in jClouds-2.0 ? Regards Archana
Re: jClouds 2.0 MultiPart Upload
It will use an internal executorservice, if i remember correctly. I don't
remember how it was configured, though, I'll have to look. Probably slow if not
even sequential.
-Zack
From: Archana C <carchan...@yahoo.co.uk>
Sent: Saturday, February 4, 2017 12:37 AM
To: user@jclouds.apache.org
Subject: Re: jClouds 2.0 MultiPart Upload
Does it mean if we are not specifying executorservice, the upload happens in
sequential ?
Regards
Archana
On Saturday, 4 February 2017, 10:34, Andrew Gaul <g...@apache.org> wrote:
PutOptions *takes* an ExecutorService which allows multiple threads to
concurrently upload multiple parts.
On Sat, Feb 04, 2017 at 03:34:30AM +, Archana C wrote:
> Hi
>
> I think the question was not clear. Parallel upload of multiple file is fine
> and that can be achieved by using executorservice.
> The question here is, does multipartUpload i.e uploading of each part is
> happening in parallel ?
> Does sequential upload of part deprecated ?
> RegardsArchana
>
>
>
>On Saturday, 4 February 2017, 1:30, Andrew Gaul
> <g...@apache.org<mailto:g...@apache.org>> wrote:
>
>
> We rewrote multi-part uploads in jclouds 2.0. You should pass an
> ExecutorService and via PutOptions in your call to BlobStore.putBlob.
>
> On Fri, Feb 03, 2017 at 01:11:15PM +, Archana C wrote:
> > Hi
> >
> > Is SequentialMultiPartUpload deprecated in jClouds2.0. Is all the multipart
> > uploads are parallel now ?
> > RegardsArchana
> >
> >On Friday, 3 February 2017, 18:39, Archana C
> > <carchan...@yahoo.co.uk<mailto:carchan...@yahoo.co.uk>> wrote:
> >
> >
> > Thanks it helped
> > RegardsArchana
> >
> >On Friday, 3 February 2017, 12:06, Ignasi Barrera
> > <n...@apache.org<mailto:n...@apache.org>> wrote:
> >
> >
> > It looks like the OOM exception is thrown when writing the wire logs. When
> > using the blob store apis you might see binary data in the logs, as the
> > "jclouds.wire" logger logs the response/request payloads which might be
> > huge for some blobs and can cause this kind of exceptions.
> > Could you try disabling the wire logs? (I recommend doing this for
> > production environments).
> > Perhaps for your use case the "jclouds.headers" are enough; that will log
> > all request/reponse path and headers but skip the bodies.
> > More on this here:https://issues.apache.org/jira/browse/JCLOUDS-1187
> > https://issues.apache.org/jira/browse/JCLOUDS-932
> >
> >
> > HTH!
> > I.
> > On Feb 3, 2017 06:22, "Archana C"
> > <carchan...@yahoo.co.uk<mailto:carchan...@yahoo.co.uk>> wrote:
> >
> > Hi
> >
> > I have written a sample code for multipart upload using jClouds-2.0
> > Properties overrides = new Properties();
> > BlobStoreContext context = ContextBuilder.newBuilder("
> > openstack-swift")
> > .endpoint("http://x.xxx.xx.xx: <http://x.xxx.xx.xx/>
> > 5000/v2.0")
> > .credentials("xx:xx", "xx")
> > .overrides(overrides)
> > .modules(modules)
> > .buildView(BlobStoreContext. class);
> > BlobStore blobStore = context.getBlobStore();
> > blobStore. createContainerInLocation( null, CONTAINER_NAME);
> > Path path = Paths.get("test2");
> > File f = new File("test2");
> > byte []byteArray = Files.readAllBytes(path);
> > Payload payload = newByteSourcePayload(wrap( byteArray));
> > PutOptions opt = new PutOptions();
> > opt.multipart();
> > Blob blob = blobStore.blobBuilder(OBJECT_ NAME)
> > .payload(payload). contentLength(f.length())
> > .build();
> > String etag = blobStore.putBlob(CONTAINER_ NAME, blob, opt);
> > test2 is the file I am trying to upload which is of size 36MB and I am
> > getting the following exception
> > 10:21:52.355 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> > Sending request 1344471693: PUT http://x.x.x.x:8091/v1/AUTH_
> > 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP HTTP/1.1
> > 10:21:52.356 [main] DEBUG jclouds.headers - >> PUT
> > http://x.x.x.x:8091/v1/AUTH_ 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP
> > HTTP/1.1
> > 10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
> > 10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
> > fd72
Re: jClouds 2.0 MultiPart Upload
Does it mean if we are not specifying executorservice, the upload happens in
sequential ?
Regards
Archana
On Saturday, 4 February 2017, 10:34, Andrew Gaul <g...@apache.org> wrote:
PutOptions *takes* an ExecutorService which allows multiple threads to
concurrently upload multiple parts.
On Sat, Feb 04, 2017 at 03:34:30AM +, Archana C wrote:
> Hi
>
> I think the question was not clear. Parallel upload of multiple file is fine
> and that can be achieved by using executorservice.
> The question here is, does multipartUpload i.e uploading of each part is
> happening in parallel ?
> Does sequential upload of part deprecated ?
> RegardsArchana
>
>
>
> On Saturday, 4 February 2017, 1:30, Andrew Gaul <g...@apache.org> wrote:
>
>
> We rewrote multi-part uploads in jclouds 2.0. You should pass an
> ExecutorService and via PutOptions in your call to BlobStore.putBlob.
>
> On Fri, Feb 03, 2017 at 01:11:15PM +, Archana C wrote:
> > Hi
> >
> > Is SequentialMultiPartUpload deprecated in jClouds2.0. Is all the multipart
> > uploads are parallel now ?
> > RegardsArchana
> >
> > On Friday, 3 February 2017, 18:39, Archana C <carchan...@yahoo.co.uk>
> >wrote:
> >
> >
> > Thanks it helped
> > RegardsArchana
> >
> > On Friday, 3 February 2017, 12:06, Ignasi Barrera <n...@apache.org>
> >wrote:
> >
> >
> > It looks like the OOM exception is thrown when writing the wire logs. When
> >using the blob store apis you might see binary data in the logs, as the
> >"jclouds.wire" logger logs the response/request payloads which might be huge
> >for some blobs and can cause this kind of exceptions.
> > Could you try disabling the wire logs? (I recommend doing this for
> > production environments).
> > Perhaps for your use case the "jclouds.headers" are enough; that will log
> > all request/reponse path and headers but skip the bodies.
> > More on this here:https://issues.apache.org/jira/browse/JCLOUDS-1187
> > https://issues.apache.org/jira/browse/JCLOUDS-932
> >
> >
> > HTH!
> > I.
> > On Feb 3, 2017 06:22, "Archana C" <carchan...@yahoo.co.uk> wrote:
> >
> > Hi
> >
> > I have written a sample code for multipart upload using jClouds-2.0
> > Properties overrides = new Properties();
> > BlobStoreContext context = ContextBuilder.newBuilder("
> > openstack-swift")
> > .endpoint("http://x.xxx.xx.xx: 5000/v2.0")
> > .credentials("xx:xx", "xx")
> > .overrides(overrides)
> > .modules(modules)
> > .buildView(BlobStoreContext. class);
> > BlobStore blobStore = context.getBlobStore();
> > blobStore. createContainerInLocation( null, CONTAINER_NAME);
> > Path path = Paths.get("test2");
> > File f = new File("test2");
> > byte []byteArray = Files.readAllBytes(path);
> > Payload payload = newByteSourcePayload(wrap( byteArray));
> > PutOptions opt = new PutOptions();
> > opt.multipart();
> > Blob blob = blobStore.blobBuilder(OBJECT_ NAME)
> > .payload(payload). contentLength(f.length())
> > .build();
> > String etag = blobStore.putBlob(CONTAINER_ NAME, blob, opt);
> > test2 is the file I am trying to upload which is of size 36MB and I am
> > getting the following exception
> > 10:21:52.355 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> > Sending request 1344471693: PUT http://x.x.x.x:8091/v1/AUTH_
> > 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP HTTP/1.1
> > 10:21:52.356 [main] DEBUG jclouds.headers - >> PUT
> > http://x.x.x.x:8091/v1/AUTH_ 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP
> > HTTP/1.1
> > 10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
> > 10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
> > fd72b74db90c46cabcca3f317d5a09 d4
> > 10:21:53.129 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> > Receiving response 1344471693: HTTP/1.1 201 Created
> > 10:21:53.129 [main] DEBUG jclouds.headers - << HTTP/1.1 201 Created
> > 10:21:53.129 [main] DEBUG jclouds.headers - << Date: Fri, 03 Feb 2017
> > 04:51:53 GMT
> > 10:21:53.129 [main] DEBUG jclouds.headers - << X-Trans-Id:
> > tx83ba6249347c43c99bb41- 0058940c68
> > 10:21:53.129 [main] DEBUG jclouds.headers
Re: jClouds 2.0 MultiPart Upload
PutOptions *takes* an ExecutorService which allows multiple threads to
concurrently upload multiple parts.
On Sat, Feb 04, 2017 at 03:34:30AM +, Archana C wrote:
> Hi
>
> I think the question was not clear. Parallel upload of multiple file is fine
> and that can be achieved by using executorservice.
> The question here is, does multipartUpload i.e uploading of each part is
> happening in parallel ?
> Does sequential upload of part deprecated ?
> RegardsArchana
>
>
>
> On Saturday, 4 February 2017, 1:30, Andrew Gaul <g...@apache.org> wrote:
>
>
> We rewrote multi-part uploads in jclouds 2.0. You should pass an
> ExecutorService and via PutOptions in your call to BlobStore.putBlob.
>
> On Fri, Feb 03, 2017 at 01:11:15PM +, Archana C wrote:
> > Hi
> >
> > Is SequentialMultiPartUpload deprecated in jClouds2.0. Is all the multipart
> > uploads are parallel now ?
> > RegardsArchana
> >
> > On Friday, 3 February 2017, 18:39, Archana C <carchan...@yahoo.co.uk>
> >wrote:
> >
> >
> > Thanks it helped
> > RegardsArchana
> >
> > On Friday, 3 February 2017, 12:06, Ignasi Barrera <n...@apache.org>
> >wrote:
> >
> >
> > It looks like the OOM exception is thrown when writing the wire logs. When
> >using the blob store apis you might see binary data in the logs, as the
> >"jclouds.wire" logger logs the response/request payloads which might be huge
> >for some blobs and can cause this kind of exceptions.
> > Could you try disabling the wire logs? (I recommend doing this for
> > production environments).
> > Perhaps for your use case the "jclouds.headers" are enough; that will log
> > all request/reponse path and headers but skip the bodies.
> > More on this here:https://issues.apache.org/jira/browse/JCLOUDS-1187
> > https://issues.apache.org/jira/browse/JCLOUDS-932
> >
> >
> > HTH!
> > I.
> > On Feb 3, 2017 06:22, "Archana C" <carchan...@yahoo.co.uk> wrote:
> >
> > Hi
> >
> > I have written a sample code for multipart upload using jClouds-2.0
> > Properties overrides = new Properties();
> > BlobStoreContext context = ContextBuilder.newBuilder("
> > openstack-swift")
> > .endpoint("http://x.xxx.xx.xx: 5000/v2.0")
> > .credentials("xx:xx", "xx")
> > .overrides(overrides)
> > .modules(modules)
> > .buildView(BlobStoreContext. class);
> > BlobStore blobStore = context.getBlobStore();
> > blobStore. createContainerInLocation( null, CONTAINER_NAME);
> > Path path = Paths.get("test2");
> > File f = new File("test2");
> > byte []byteArray = Files.readAllBytes(path);
> > Payload payload = newByteSourcePayload(wrap( byteArray));
> > PutOptions opt = new PutOptions();
> > opt.multipart();
> > Blob blob = blobStore.blobBuilder(OBJECT_ NAME)
> > .payload(payload). contentLength(f.length())
> > .build();
> > String etag = blobStore.putBlob(CONTAINER_ NAME, blob, opt);
> > test2 is the file I am trying to upload which is of size 36MB and I am
> > getting the following exception
> > 10:21:52.355 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> > Sending request 1344471693: PUT http://x.x.x.x:8091/v1/AUTH_
> > 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP HTTP/1.1
> > 10:21:52.356 [main] DEBUG jclouds.headers - >> PUT
> > http://x.x.x.x:8091/v1/AUTH_ 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP
> > HTTP/1.1
> > 10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
> > 10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
> > fd72b74db90c46cabcca3f317d5a09 d4
> > 10:21:53.129 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> > Receiving response 1344471693: HTTP/1.1 201 Created
> > 10:21:53.129 [main] DEBUG jclouds.headers - << HTTP/1.1 201 Created
> > 10:21:53.129 [main] DEBUG jclouds.headers - << Date: Fri, 03 Feb 2017
> > 04:51:53 GMT
> > 10:21:53.129 [main] DEBUG jclouds.headers - << X-Trans-Id:
> > tx83ba6249347c43c99bb41- 0058940c68
> > 10:21:53.129 [main] DEBUG jclouds.headers - << Connection: keep-alive
> > 10:21:53.129 [main] DEBUG jclouds.headers - << Content-Type: text/html;
> > charset=UTF-8
> > 10:21:53.129 [main] DEBUG jclouds.header
Re: jClouds 2.0 MultiPart Upload
Hi
I think the question was not clear. Parallel upload of multiple file is fine
and that can be achieved by using executorservice.
The question here is, does multipartUpload i.e uploading of each part is
happening in parallel ?
Does sequential upload of part deprecated ?
RegardsArchana
On Saturday, 4 February 2017, 1:30, Andrew Gaul <g...@apache.org> wrote:
We rewrote multi-part uploads in jclouds 2.0. You should pass an
ExecutorService and via PutOptions in your call to BlobStore.putBlob.
On Fri, Feb 03, 2017 at 01:11:15PM +, Archana C wrote:
> Hi
>
> Is SequentialMultiPartUpload deprecated in jClouds2.0. Is all the multipart
> uploads are parallel now ?
> RegardsArchana
>
> On Friday, 3 February 2017, 18:39, Archana C <carchan...@yahoo.co.uk>
>wrote:
>
>
> Thanks it helped
> RegardsArchana
>
> On Friday, 3 February 2017, 12:06, Ignasi Barrera <n...@apache.org> wrote:
>
>
> It looks like the OOM exception is thrown when writing the wire logs. When
>using the blob store apis you might see binary data in the logs, as the
>"jclouds.wire" logger logs the response/request payloads which might be huge
>for some blobs and can cause this kind of exceptions.
> Could you try disabling the wire logs? (I recommend doing this for production
> environments).
> Perhaps for your use case the "jclouds.headers" are enough; that will log all
> request/reponse path and headers but skip the bodies.
> More on this here:https://issues.apache.org/jira/browse/JCLOUDS-1187
> https://issues.apache.org/jira/browse/JCLOUDS-932
>
>
> HTH!
> I.
> On Feb 3, 2017 06:22, "Archana C" <carchan...@yahoo.co.uk> wrote:
>
> Hi
>
> I have written a sample code for multipart upload using jClouds-2.0
> Properties overrides = new Properties();
> BlobStoreContext context = ContextBuilder.newBuilder("
> openstack-swift")
> .endpoint("http://x.xxx.xx.xx: 5000/v2.0")
> .credentials("xx:xx", "xx")
> .overrides(overrides)
> .modules(modules)
> .buildView(BlobStoreContext. class);
> BlobStore blobStore = context.getBlobStore();
> blobStore. createContainerInLocation( null, CONTAINER_NAME);
> Path path = Paths.get("test2");
> File f = new File("test2");
> byte []byteArray = Files.readAllBytes(path);
> Payload payload = newByteSourcePayload(wrap( byteArray));
> PutOptions opt = new PutOptions();
> opt.multipart();
> Blob blob = blobStore.blobBuilder(OBJECT_ NAME)
> .payload(payload). contentLength(f.length())
> .build();
> String etag = blobStore.putBlob(CONTAINER_ NAME, blob, opt);
> test2 is the file I am trying to upload which is of size 36MB and I am
> getting the following exception
> 10:21:52.355 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> Sending request 1344471693: PUT http://x.x.x.x:8091/v1/AUTH_
> 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP HTTP/1.1
> 10:21:52.356 [main] DEBUG jclouds.headers - >> PUT
> http://x.x.x.x:8091/v1/AUTH_ 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP
> HTTP/1.1
> 10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
> 10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
> fd72b74db90c46cabcca3f317d5a09 d4
> 10:21:53.129 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
> Receiving response 1344471693: HTTP/1.1 201 Created
> 10:21:53.129 [main] DEBUG jclouds.headers - << HTTP/1.1 201 Created
> 10:21:53.129 [main] DEBUG jclouds.headers - << Date: Fri, 03 Feb 2017
> 04:51:53 GMT
> 10:21:53.129 [main] DEBUG jclouds.headers - << X-Trans-Id:
> tx83ba6249347c43c99bb41- 0058940c68
> 10:21:53.129 [main] DEBUG jclouds.headers - << Connection: keep-alive
> 10:21:53.129 [main] DEBUG jclouds.headers - << Content-Type: text/html;
> charset=UTF-8
> 10:21:53.129 [main] DEBUG jclouds.headers - << Content-Length: 0
> ---> Container Creation Successful
> 10:21:53.373 [user thread 1] DEBUG o.j.rest.internal. InvokeHttpMethod - >>
> invoking object:put
> 10:21:53.373 [user thread 0] DEBUG o.j.rest.internal. InvokeHttpMethod - >>
> invoking object:put
> 10:21:53.374 [user thread 1] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ
> ice - Sending request 823625484: PUT http://x.x.x.x:8091/v1/AUTH_
> 0909ac10e7024847b1a9fe9787c7de 8f/arctestMP/arc/slo/
> 1486097513.327000/0/33554432/ 0001 HTTP/1.1
> 10:21:53.376 [user thread 0] DEBUG o.j.h.i. JavaUrlHttpCommandExecutor
Re: jClouds 2.0 MultiPart Upload
Hi
Is SequentialMultiPartUpload deprecated in jClouds2.0. Is all the multipart
uploads are parallel now ?
RegardsArchana
On Friday, 3 February 2017, 18:39, Archana C <carchan...@yahoo.co.uk> wrote:
Thanks it helped
RegardsArchana
On Friday, 3 February 2017, 12:06, Ignasi Barrera <n...@apache.org> wrote:
It looks like the OOM exception is thrown when writing the wire logs. When
using the blob store apis you might see binary data in the logs, as the
"jclouds.wire" logger logs the response/request payloads which might be huge
for some blobs and can cause this kind of exceptions.
Could you try disabling the wire logs? (I recommend doing this for production
environments).
Perhaps for your use case the "jclouds.headers" are enough; that will log all
request/reponse path and headers but skip the bodies.
More on this here:https://issues.apache.org/jira/browse/JCLOUDS-1187
https://issues.apache.org/jira/browse/JCLOUDS-932
HTH!
I.
On Feb 3, 2017 06:22, "Archana C" <carchan...@yahoo.co.uk> wrote:
Hi
I have written a sample code for multipart upload using jClouds-2.0
Properties overrides = new Properties();
BlobStoreContext context = ContextBuilder.newBuilder(" openstack-swift")
.endpoint("http://x.xxx.xx.xx: 5000/v2.0")
.credentials("xx:xx", "xx")
.overrides(overrides)
.modules(modules)
.buildView(BlobStoreContext. class);
BlobStore blobStore = context.getBlobStore();
blobStore. createContainerInLocation( null, CONTAINER_NAME);
Path path = Paths.get("test2");
File f = new File("test2");
byte []byteArray = Files.readAllBytes(path);
Payload payload = newByteSourcePayload(wrap( byteArray));
PutOptions opt = new PutOptions();
opt.multipart();
Blob blob = blobStore.blobBuilder(OBJECT_ NAME)
.payload(payload). contentLength(f.length())
.build();
String etag = blobStore.putBlob(CONTAINER_ NAME, blob, opt);
test2 is the file I am trying to upload which is of size 36MB and I am getting
the following exception
10:21:52.355 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice - Sending
request 1344471693: PUT http://x.x.x.x:8091/v1/AUTH_
0909ac10e7024847b1a9fe9787c7de 8f/arctestMP HTTP/1.1
10:21:52.356 [main] DEBUG jclouds.headers - >> PUT http://x.x.x.x:8091/v1/AUTH_
0909ac10e7024847b1a9fe9787c7de 8f/arctestMP HTTP/1.1
10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
fd72b74db90c46cabcca3f317d5a09 d4
10:21:53.129 [main] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice -
Receiving response 1344471693: HTTP/1.1 201 Created
10:21:53.129 [main] DEBUG jclouds.headers - << HTTP/1.1 201 Created
10:21:53.129 [main] DEBUG jclouds.headers - << Date: Fri, 03 Feb 2017 04:51:53
GMT
10:21:53.129 [main] DEBUG jclouds.headers - << X-Trans-Id:
tx83ba6249347c43c99bb41- 0058940c68
10:21:53.129 [main] DEBUG jclouds.headers - << Connection: keep-alive
10:21:53.129 [main] DEBUG jclouds.headers - << Content-Type: text/html;
charset=UTF-8
10:21:53.129 [main] DEBUG jclouds.headers - << Content-Length: 0
---> Container Creation Successful
10:21:53.373 [user thread 1] DEBUG o.j.rest.internal. InvokeHttpMethod - >>
invoking object:put
10:21:53.373 [user thread 0] DEBUG o.j.rest.internal. InvokeHttpMethod - >>
invoking object:put
10:21:53.374 [user thread 1] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice
- Sending request 823625484: PUT http://x.x.x.x:8091/v1/AUTH_
0909ac10e7024847b1a9fe9787c7de 8f/arctestMP/arc/slo/
1486097513.327000/0/33554432/ 0001 HTTP/1.1
10:21:53.376 [user thread 0] DEBUG o.j.h.i. JavaUrlHttpCommandExecutorServ ice
- Sending request -1220101806: PUT http://x.x.x.x:8091/v1/AUTH_
0909ac10e7024847b1a9fe9787c7de 8f/arctestMP/arc/slo/
1486097513.327000/0/33554432/ HTTP/1.1
10:21:53.396 [user thread 1] DEBUG org.jclouds.http.internal. HttpWire - over
limit 3145728/262144: wrote temp file
10:21:53.552 [user thread 0] DEBUG org.jclouds.http.internal. HttpWire - over
limit 33554432/262144: wrote temp fileException in thread "main"
com.google.common.util. concurrent.ExecutionError: java.lang.OutOfMemoryError:
Java heap space
at com.google.common.util. concurrent.Futures.
wrapAndThrowUnchecked(Futures. java:1380)
at com.google.common.util. concurrent.Futures. getUnchecked(Futures.java:
1373)
at org.jclouds.openstack.swift. v1.blobstore. RegionScopedSwiftBlobStore.
putMultipartBlob( RegionScopedSwiftBlobStore. java:650)
at org.jclouds.openstack.swift. v1.blobstore. RegionScopedSwiftBlobStore.
putMultipartBlob( RegionScopedSwiftBlobStore. java:628)
at org.jclou
Re: jClouds 2.0 MultiPart Upload
It looks like the OOM exception is thrown when writing the wire logs. When
using the blob store apis you might see binary data in the logs, as the
"jclouds.wire" logger logs the response/request payloads which might be
huge for some blobs and can cause this kind of exceptions.
Could you try disabling the wire logs? (I recommend doing this for
production environments).
Perhaps for your use case the "jclouds.headers" are enough; that will log
all request/reponse path and headers but skip the bodies.
More on this here:
https://issues.apache.org/jira/browse/JCLOUDS-1187
https://issues.apache.org/jira/browse/JCLOUDS-932
HTH!
I.
On Feb 3, 2017 06:22, "Archana C" <carchan...@yahoo.co.uk> wrote:
> Hi
>
> *I have written a sample code for multipart upload using jClouds-2.0*
>
> Properties overrides = new Properties();
> BlobStoreContext context = ContextBuilder.newBuilder("
> openstack-swift")
> .endpoint("http://x.xxx.xx.xx:5000/v2.0;)
> .credentials("xx:xx", "xx")
> .overrides(overrides)
> .modules(modules)
> .buildView(BlobStoreContext.class);
> BlobStore blobStore = context.getBlobStore();
> blobStore.createContainerInLocation(null, CONTAINER_NAME);
> Path path = Paths.get("test2");
> File f = new File("test2");
> byte []byteArray = Files.readAllBytes(path);
> Payload payload = newByteSourcePayload(wrap(byteArray));
> PutOptions opt = new PutOptions();
> opt.multipart();
> Blob blob = blobStore.blobBuilder(OBJECT_NAME)
> .payload(payload).contentLength(f.length())
> .build();
> String etag = blobStore.putBlob(CONTAINER_NAME, blob, opt);
>
> *test2 is the file I am trying to upload which is of size 36MB and I am
> getting the following exception*
>
> 10:21:52.355 [main] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService -
> Sending request 1344471693: PUT http://x.x.x.x:8091/v1/AUTH_
> 0909ac10e7024847b1a9fe9787c7de8f/arctestMP HTTP/1.1
> 10:21:52.356 [main] DEBUG jclouds.headers - >> PUT
> http://x.x.x.x:8091/v1/AUTH_0909ac10e7024847b1a9fe9787c7de8f/arctestMP
> HTTP/1.1
> 10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
> 10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
> fd72b74db90c46cabcca3f317d5a09d4
> 10:21:53.129 [main] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService -
> Receiving response 1344471693: HTTP/1.1 201 Created
> 10:21:53.129 [main] DEBUG jclouds.headers - << HTTP/1.1 201 Created
> 10:21:53.129 [main] DEBUG jclouds.headers - << Date: Fri, 03 Feb 2017
> 04:51:53 GMT
> 10:21:53.129 [main] DEBUG jclouds.headers - << X-Trans-Id:
> tx83ba6249347c43c99bb41-0058940c68
> 10:21:53.129 [main] DEBUG jclouds.headers - << Connection: keep-alive
> 10:21:53.129 [main] DEBUG jclouds.headers - << Content-Type: text/html;
> charset=UTF-8
> 10:21:53.129 [main] DEBUG jclouds.headers - << Content-Length: 0
> ---> *Container Creation Successful*
> 10:21:53.373 [user thread 1] DEBUG o.j.rest.internal.InvokeHttpMethod -
> >> invoking object:put
> 10:21:53.373 [user thread 0] DEBUG o.j.rest.internal.InvokeHttpMethod -
> >> invoking object:put
> 10:21:53.374 [user thread 1] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService
> - Sending request 823625484: PUT http://x.x.x.x:8091/v1/AUTH_
> 0909ac10e7024847b1a9fe9787c7de8f/arctestMP/arc/slo/
> 1486097513.327000/0/33554432/0001 HTTP/1.1
> 10:21:53.376 [user thread 0] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService
> - Sending request -1220101806: PUT http://x.x.x.x:8091/v1/AUTH_
> 0909ac10e7024847b1a9fe9787c7de8f/arctestMP/arc/slo/
> 1486097513.327000/0/33554432/ HTTP/1.1
> 10:21:53.396 [user thread 1] DEBUG org.jclouds.http.internal.HttpWire -
> over limit* 3145728/262144*: wrote temp file
> 10:21:53.552 [user thread 0] DEBUG org.jclouds.http.internal.HttpWire -
> over limit* 33554432/262144*: wrote temp file
> Exception in thread "main" com.google.common.util.concurrent.ExecutionError:
> java.lang.OutOfMemoryError: Java heap space
> at com.google.common.util.concurrent.Futures.
> wrapAndThrowUnchecked(Futures.java:1380)
> at com.google.common.util.concurrent.Futures.
> getUnchecked(Futures.java:1373)
> at org.jclouds.openstack.swift.v1.blobstore.
> RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.
> java:650)
> at org.jclouds.openstack.swift.v1.blobstore.
> RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.
> java:628)
> at org.jcloud
jClouds 2.0 MultiPart Upload
Hi
I have written a sample code for multipart upload using jClouds-2.0
Properties overrides = new Properties();
BlobStoreContext context = ContextBuilder.newBuilder("openstack-swift")
.endpoint("http://x.xxx.xx.xx:5000/v2.0;)
.credentials("xx:xx", "xx")
.overrides(overrides)
.modules(modules)
.buildView(BlobStoreContext.class);
BlobStore blobStore = context.getBlobStore();
blobStore.createContainerInLocation(null, CONTAINER_NAME);
Path path = Paths.get("test2");
File f = new File("test2");
byte []byteArray = Files.readAllBytes(path);
Payload payload = newByteSourcePayload(wrap(byteArray));
PutOptions opt = new PutOptions();
opt.multipart();
Blob blob = blobStore.blobBuilder(OBJECT_NAME)
.payload(payload).contentLength(f.length())
.build();
String etag = blobStore.putBlob(CONTAINER_NAME, blob, opt);
test2 is the file I am trying to upload which is of size 36MB and I am getting
the following exception
10:21:52.355 [main] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService - Sending
request 1344471693: PUT
http://x.x.x.x:8091/v1/AUTH_0909ac10e7024847b1a9fe9787c7de8f/arctestMP HTTP/1.1
10:21:52.356 [main] DEBUG jclouds.headers - >> PUT
http://x.x.x.x:8091/v1/AUTH_0909ac10e7024847b1a9fe9787c7de8f/arctestMP HTTP/1.1
10:21:52.356 [main] DEBUG jclouds.headers - >> Accept: application/json
10:21:52.357 [main] DEBUG jclouds.headers - >> X-Auth-Token:
fd72b74db90c46cabcca3f317d5a09d4
10:21:53.129 [main] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService - Receiving
response 1344471693: HTTP/1.1 201 Created
10:21:53.129 [main] DEBUG jclouds.headers - << HTTP/1.1 201 Created
10:21:53.129 [main] DEBUG jclouds.headers - << Date: Fri, 03 Feb 2017 04:51:53
GMT
10:21:53.129 [main] DEBUG jclouds.headers - << X-Trans-Id:
tx83ba6249347c43c99bb41-0058940c68
10:21:53.129 [main] DEBUG jclouds.headers - << Connection: keep-alive
10:21:53.129 [main] DEBUG jclouds.headers - << Content-Type: text/html;
charset=UTF-8
10:21:53.129 [main] DEBUG jclouds.headers - << Content-Length: 0
---> Container Creation Successful
10:21:53.373 [user thread 1] DEBUG o.j.rest.internal.InvokeHttpMethod - >>
invoking object:put
10:21:53.373 [user thread 0] DEBUG o.j.rest.internal.InvokeHttpMethod - >>
invoking object:put
10:21:53.374 [user thread 1] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService -
Sending request 823625484: PUT
http://x.x.x.x:8091/v1/AUTH_0909ac10e7024847b1a9fe9787c7de8f/arctestMP/arc/slo/1486097513.327000/0/33554432/0001
HTTP/1.1
10:21:53.376 [user thread 0] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService -
Sending request -1220101806: PUT
http://x.x.x.x:8091/v1/AUTH_0909ac10e7024847b1a9fe9787c7de8f/arctestMP/arc/slo/1486097513.327000/0/33554432/
HTTP/1.1
10:21:53.396 [user thread 1] DEBUG org.jclouds.http.internal.HttpWire - over
limit 3145728/262144: wrote temp file
10:21:53.552 [user thread 0] DEBUG org.jclouds.http.internal.HttpWire - over
limit 33554432/262144: wrote temp fileException in thread "main"
com.google.common.util.concurrent.ExecutionError: java.lang.OutOfMemoryError:
Java heap space
at
com.google.common.util.concurrent.Futures.wrapAndThrowUnchecked(Futures.java:1380)
at com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1373)
at
org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:650)
at
org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:628)
at
org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:274)
at jclouds20.App.main(App.java:83)
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.lang.StringBuilder.ensureCapacityImpl(StringBuilder.java:342)
at java.lang.StringBuilder.append(StringBuilder.java:208)
at org.jclouds.logging.internal.Wire.wire(Wire.java:68)
at org.jclouds.logging.internal.Wire.copy(Wire.java:99)
at org.jclouds.logging.internal.Wire.output(Wire.java:176)
at org.jclouds.logging.internal.Wire.output(Wire.java:143)
at org.jclouds.http.HttpUtils.wirePayloadIfEnabled(HttpUtils.java:296)
at
org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:97)
at
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90)
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:11
