[jira] [Commented] (JCLOUDS-1366) OutOfMemory when InputStream referencing to big file is used as payload
[
https://issues.apache.org/jira/browse/JCLOUDS-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313118#comment-16313118
]
Zack Shoylev commented on JCLOUDS-1366:
---
If I remember correctly, only a certain amount of parts should be prepared
(instead of all of them). The ExecutorService prepare loop is supposed to block
after the job queue is full. There could be some problem with the
implementation, though.
> OutOfMemory when InputStream referencing to big file is used as payload
> ---
>
> Key: JCLOUDS-1366
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1366
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0, 2.0.3
> Environment: Linux and Windows
>Reporter: Deyan
>Priority: Critical
>
> If I use InputStream which source is large file (lets say 3GB) I am getting
> OOE. This is with default java VM options.
> Here is the code I am using to construct the blob:
> {code:java}
> File bigFile = new File(file);
> try (InputStream inputStream = new FileInputStream(f)) {
> Blob b = blobStore.blobBuilder(blobName)
> .payload(inputStream).contentLength(f.length())
> .contentDisposition(blobName)
> .contentType(
> MediaType.OCTET_STREAM)
> .userMetadata(ImmutableMap.of("a", "b", "test",
> "beta"))
> .build();
> blobStore.putBlob("test", b, multipart());
> }
> {code}
> Stacktrace:
> {code:java}
> java.lang.OutOfMemoryError: Java heap space
> at
> org.jclouds.io.internal.BasePayloadSlicer$InputStreamPayloadIterator.getNextPayload(BasePayloadSlicer.java:101)
> at
> org.jclouds.io.internal.BasePayloadSlicer$InputStreamPayloadIterator.next(BasePayloadSlicer.java:90)
> at
> org.jclouds.io.internal.BasePayloadSlicer$InputStreamPayloadIterator.next(BasePayloadSlicer.java:63)
> at
> org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:363)
> at
> org.jclouds.blobstore.internal.BaseBlobStore.putMultipartBlob(BaseBlobStore.java:349)
> at org.jclouds.s3.blobstore.S3BlobStore.putBlob(S3BlobStore.java:262)
> {code}
> If 'bigFile' is used as payload the bug is not reproducible.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCLOUDS-1251) Swift removeBlob
[
https://issues.apache.org/jira/browse/JCLOUDS-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890686#comment-15890686
]
Zack Shoylev commented on JCLOUDS-1251:
---
Can you add code that reproduces the issue and also the wire log as per
https://jclouds.apache.org/reference/logging/
> Swift removeBlob
>
>
> Key: JCLOUDS-1251
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1251
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: RHEl 7
> Java 1.7
>Reporter: Archana Chinnaiah
>Priority: Blocker
>
> RemoveBlob for swift is unsuccessful, and fails with the following error
> Mar 01, 2017 12:08:50 PM org.jclouds.logging.jdk.JDKLogger logError
> SEVERE: Error parsing input: null
> java.lang.NullPointerException
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:60)
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:41)
> 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:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
> at com.sun.proxy.$Proxy73.delete(Unknown Source)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.removeBlob(RegionScopedSwiftBlobStore.java:393)
> at main.java.s3_19.App.main(App.java:106)
> Exception in thread "main" org.jclouds.http.HttpResponseException: Error
> parsing input: null
> {statusCode=204, message=No Content, headers={Date=[Wed, 01 Mar 2017 06:46:49
> GMT], X-Trans-Id=[txa66b195a2b4b4723931ca-0058b66e59],
> Connection=[keep-alive]}}
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:67)
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:41)
> 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:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
> at com.sun.proxy.$Proxy73.delete(Unknown Source)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.removeBlob(RegionScopedSwiftBlobStore.java:393)
> at main.java.s3_19.App.main(App.java:106)
> Caused by: java.lang.NullPointerException
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:60)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (JCLOUDS-1240) MultiPart Upload Swift
[ https://issues.apache.org/jira/browse/JCLOUDS-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870274#comment-15870274 ] Zack Shoylev commented on JCLOUDS-1240: --- Interesting. As per https://docs.openstack.org/developer/swift/overview_large_objects.html I am wondering if the swift stat command uses ?multipart-manifest=get or ?multipart-manifest=get=raw This is how we get the content-length of a SLO using jclouds that seems to work: long contentLength = api .getObjectApi(regionId, container) .getWithoutBody(name) .getPayload() .getContentMetadata() .getContentLength(); which is to say I am not aware of us having to do anything extra to get it to work as per the doc. > MultiPart Upload Swift > -- > > Key: JCLOUDS-1240 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1240 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.0.0 > Environment: RHEL 7.2 > jClouds 2.0.0 > Swift Version 2.10.0-2 >Reporter: Archana Chinnaiah > Attachments: SwiftMPU > > > Content length of the manifest file for multipart upload in swift doesnot > have size of entire blob instead it has the content length of the manifest > file.As per the javadoc [1] Content-Length of the manifest must be size of > the blob. > [1] > https://github.com/jclouds/jclouds/blob/master/apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/binders/BindManifestToJsonPayload.java > As per my observation content length of the manifest has is not content > length of the blob. > [root@jupiter-vm564 ~]# swift list arctestAPI > arc > arc/slo/1487235018.498000/10485839/0/0001 > arc/slo/1487235018.498000/10485839/0/0002 > [root@jupiter-vm564 ~]# swift stat arctestAPI arc > Account: AUTH_f9d7c1cf6500469b80f0906f5f9b1791 > Container: arctestAPI > Object: arc > Content Type: application/unknown > Content Length: 264 > Last Modified: Thu, 16 Feb 2017 08:58:43 GMT > ETag: fcd3ba56d354c8819d186eed4eee115d > Content-Disposition: arc > Accept-Ranges: bytes > Connection: keep-alive > X-Timestamp: 1487235522.85407 > X-Trans-Id: tx1ca4d8c67a4f4cfa996b4-0058a569e3 > [root@jupiter-vm564 ~]# swift stat arctestAPI > arc/slo/1487235018.498000/10485839/0/0001 >Account: AUTH_f9d7c1cf6500469b80f0906f5f9b1791 >Container: arctestAPI >Object: arc/slo/1487235018.498000/10485839/0/0001 >Content Type: application/unknown >Content Length: 33554432 >Last Modified: Thu, 16 Feb 2017 08:58:29 GMT >ETag: 58f06dd588d8ffb3beb46ada6309436b >Content-Disposition: arc >Accept-Ranges: bytes >Connection: keep-alive >X-Timestamp: 1487235508.56703 >X-Trans-Id: txdaeb6b9e4e5a4ae0a1ec8-0058a56a41 > [root@jupiter-vm564 ~]# swift stat arctestAPI > arc/slo/1487235018.498000/10485839/0/0002 > Account: AUTH_f9d7c1cf6500469b80f0906f5f9b1791 > Container: arctestAPI > Object: arc/slo/1487235018.498000/10485839/0/0002 > Content Type: application/unknown > Content Length: 3145728 >Last Modified: Thu, 16 Feb 2017 08:58:42 GMT >ETag: d1dd210d6b1312cb342b56d02bd5e651 > Content-Disposition: arc > Accept-Ranges: bytes > Connection: keep-alive > X-Timestamp: 1487235521.06353 > X-Trans-Id: txacf9546117e345d48921f-0058a56a48 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCLOUDS-1225) Guava 21 compatibility
[ https://issues.apache.org/jira/browse/JCLOUDS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15824705#comment-15824705 ] Zack Shoylev commented on JCLOUDS-1225: --- Are there good reasons to not shade it, besides the import churn? I think some APIs expose guava classes or interfaces so that might be a point of concern, but unsure how serious. Otherwise [~ian.springer] makes a good point, and I wonder if we might get some additional benefits to jclouds internally out of it (would that allow us to upgrade the version of guava we use?) > Guava 21 compatibility > -- > > Key: JCLOUDS-1225 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1225 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.0.0 >Reporter: Ian Springer > Labels: guava > > The below classes use com.google.common.base.Objects.ToStringHelper, which > has been deprecated since Guava 18, and has been removed in Guava 21. This > makes it impossible to use jclouds in a project using Guava 21. Please either > upgrade to Guava 18+ and switch to using > com.google.common.base.MoreObjects.ToStringHelper, or drop the usage of > ToStringHelper altogether. This will allow my project to upgrade to Guava 21 > without having to use a fork of jclouds. > * org/jclouds/apis/internal/BaseApiMetadata.java > * org/jclouds/domain/internal/LocationImpl.java > * org/jclouds/domain/internal/MutableResourceMetadataImpl.java > * org/jclouds/domain/internal/ResourceMetadataImpl.java > * org/jclouds/http/HttpMessage.java > * org/jclouds/http/HttpRequest.java > * org/jclouds/http/HttpResponse.java > * org/jclouds/internal/BaseView.java > * org/jclouds/providers/internal/BaseProviderMetadata.java > * org/jclouds/reflect/InvocationSuccess.java > * org/jclouds/rest/internal/BaseHttpApiMetadata.java > * org/jclouds/rest/suppliers/URIFromStringSupplier.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCLOUDS-487) Return ordered IP addresses from server details
[ https://issues.apache.org/jira/browse/JCLOUDS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev closed JCLOUDS-487. Resolution: Workaround Fix Version/s: (was: 2.1.0) 1.9.2 > Return ordered IP addresses from server details > --- > > Key: JCLOUDS-487 > URL: https://issues.apache.org/jira/browse/JCLOUDS-487 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 1.7.1, 1.8.0 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > Fix For: 1.9.2 > > > NodeMetadata.getPrivateAddresses() returns a list of addresses in random > order. These should be returned in a particular order (as listed by the > service). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev resolved JCLOUDS-1064.
---
Resolution: Fixed
Fix Version/s: 2.0.0
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
> Fix For: 2.0.0
>
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1222) UserPrincipalNotFound with a french Windows
[ https://issues.apache.org/jira/browse/JCLOUDS-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816037#comment-15816037 ] Zack Shoylev commented on JCLOUDS-1222: --- https://github.com/jclouds/jclouds/pull/1049 > UserPrincipalNotFound with a french Windows > --- > > Key: JCLOUDS-1222 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1222 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.0.0 > Environment: Windows >Reporter: IG >Priority: Minor > Fix For: 2.0.1 > > > French for Everyone is « Tout le monde ». > The line.split() fails. > The following pull request solves this issue > https://github.com/jclouds/jclouds/pull/1049 > It can be added to 2.0.x patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1222) UserPrincipalNotFound with a french Windows
[ https://issues.apache.org/jira/browse/JCLOUDS-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-1222. --- Resolution: Fixed > UserPrincipalNotFound with a french Windows > --- > > Key: JCLOUDS-1222 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1222 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.0.0 > Environment: Windows >Reporter: IG >Priority: Minor > Fix For: 2.0.1 > > > French for Everyone is « Tout le monde ». > The line.split() fails. > The following pull request solves this issue > https://github.com/jclouds/jclouds/pull/1049 > It can be added to 2.0.x patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15732417#comment-15732417
]
Zack Shoylev commented on JCLOUDS-1064:
---
I think it's very likely this got fixed in 2.0.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-864) Neutron Security Group Rule requires port ranges when it should not
[ https://issues.apache.org/jira/browse/JCLOUDS-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-864. -- Resolution: Fixed Fix Version/s: (was: 2.1.0) 1.9.3 > Neutron Security Group Rule requires port ranges when it should not > --- > > Key: JCLOUDS-864 > URL: https://issues.apache.org/jira/browse/JCLOUDS-864 > Project: jclouds > Issue Type: Bug > Components: jclouds-labs-openstack >Affects Versions: 1.9.0 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > Fix For: 1.9.3 > > > Port range min/max are optional, however the code will throw an NPE here if > they are not present: > https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2/domain/Rule.java#L370 > Clearly this check is wrong. > Also: probably good idea to remove the validation checks completely, as this > is something we are moving away from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent
[
https://issues.apache.org/jira/browse/JCLOUDS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15635983#comment-15635983
]
Zack Shoylev commented on JCLOUDS-1176:
---
Please reopen if you can still see this with 2.0.0 but also provide code to
reproduce with. Thanks!
> Swift delete operation is not idempotent
>
>
> Key: JCLOUDS-1176
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1176
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: Vijay Panghal
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> Openstack Swift delete operation used to be idempotent. But after this pull
> request https://github.com/jclouds/jclouds/pull/700
> second delete is failing with these stack trace
> {quote}
> org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed
> connecting to DELETE
> https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f
> HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy67.removeObject(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> at com.sun.proxy.$Proxy69.removeBlob(Unknown Source)
> at
> com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
[jira] [Closed] (JCLOUDS-1176) Swift delete operation is not idempotent
[
https://issues.apache.org/jira/browse/JCLOUDS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev closed JCLOUDS-1176.
-
Resolution: Fixed
Fix Version/s: 2.0.0
> Swift delete operation is not idempotent
>
>
> Key: JCLOUDS-1176
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1176
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: Vijay Panghal
>Assignee: Zack Shoylev
> Labels: openstack-swift
> Fix For: 2.0.0
>
>
> Openstack Swift delete operation used to be idempotent. But after this pull
> request https://github.com/jclouds/jclouds/pull/700
> second delete is failing with these stack trace
> {quote}
> org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed
> connecting to DELETE
> https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f
> HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy67.removeObject(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> at com.sun.proxy.$Proxy69.removeBlob(Unknown Source)
> at
> com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent
[
https://issues.apache.org/jira/browse/JCLOUDS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15635978#comment-15635978
]
Zack Shoylev commented on JCLOUDS-1176:
---
I cannot reproduce using latest code in 2.0.0 either with or without
https://github.com/jclouds/jclouds/pull/1031
> Swift delete operation is not idempotent
>
>
> Key: JCLOUDS-1176
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1176
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: Vijay Panghal
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> Openstack Swift delete operation used to be idempotent. But after this pull
> request https://github.com/jclouds/jclouds/pull/700
> second delete is failing with these stack trace
> {quote}
> org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed
> connecting to DELETE
> https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f
> HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy67.removeObject(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> at com.sun.proxy.$Proxy69.removeBlob(Unknown Source)
> at
> com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
[jira] [Resolved] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-1179. --- Resolution: Fixed Fix Version/s: 2.0.0 > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > Fix For: 2.0.0 > > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571973#comment-15571973 ] Zack Shoylev commented on JCLOUDS-1179: --- [~nacx] Yep. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566357#comment-15566357 ] Zack Shoylev commented on JCLOUDS-1179: --- https://github.com/jclouds/jclouds/pull/1018 The tests for this were pretty much impossible with our current version of mock web server (https://github.com/square/okhttp/issues/675), and there were some problems with running a live test as well. I tested against a separate piece of code, but I added a test that would work eventually. This should address this same problem for other providers that use http 1.1 with 100-continue. This seems to be a somewhat common problem (https://curl.haxx.se/mail/lib-2004-08/0002.html). > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549174#comment-15549174 ] Zack Shoylev commented on JCLOUDS-1179: --- Good to know, thanks! I was confused because of what seems like devstack not properly expiring the token (only sometimes), even though the expiration is properly set and works most of the time. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548995#comment-15548995 ] Zack Shoylev commented on JCLOUDS-1179: --- Scratch that, it seems I am still hitting the issue. That is actually less weird. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[
https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548896#comment-15548896
]
Zack Shoylev commented on JCLOUDS-1179:
---
[~nhowes] I had a long look at this bug. I was having some issues reproducing
it with a unit test in combination with running against the JVMs that should be
exhibiting this problem.
In the end, I followed your instructions to setup a devstack server and tested
using your example code, and I was able to reproduce the issue using the
example code.
However, if you modify your build.gradle file to this:
{code}
// Apply the java plugin to add support for Java
apply plugin: 'java'
apply plugin: 'application'
mainClassName = "Swift"
repositories {
jcenter()
maven { url "http://repository.apache.org/snapshots/; }
}
// In this section you declare the dependencies for your production and test
code
dependencies {
compile 'ch.qos.logback:logback-classic:1.1.3'
compile 'org.slf4j:slf4j-api:1.7.13'
compile "org.apache.jclouds.api:openstack-swift:2.0.0-SNAPSHOT"
compile "org.apache.jclouds.driver:jclouds-slf4j:2.0.0-SNAPSHOT"
}
task wrapper(type: Wrapper) {
gradleVersion = '3.0'
}
{code}
you should see the problem go away (at least in the example you have provided).
The reason appears to be that using jclouds-all would produce this unintended
interaction you are describing, probably as a side-effect of how it is bundled.
In general, it is better to use the specific modules that you need.
I am not closing the issue yet, in case I am missing something (please let me
know). Also, I will be adding the unit test to jclouds just in case. Finally,
we might also have to have a look at jclouds-all.
> putBlob doesn't handle 401s
>
>
> Key: JCLOUDS-1179
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1179
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.2, 2.0.0
> Environment: Devstack on Ubuntu 14.04
>Reporter: Nick Howes
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> After the token used by jclouds expires, subsequent `putBlob` requests to
> swift fail with 401.
> Unlike other operations, the `putBlob` command does not resolve this by
> `POST`ing to keystone, but instead tries a few times to `PUT` the blob to
> swift. Each request fails with a 401 and then it gives up.
> Other operations such as a get _will_ handle a retry by refreshing the auth
> token, after which subsequent puts work (until the next expiry)
> Project to reproduce can be found here
> https://github.com/UniversityofWarwick/jclouds-bug
> It should be noted that when running this script I have altered [token]
> expiration in /etc/keystone/keystone.conf to be 2 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497270#comment-15497270 ] Zack Shoylev commented on JCLOUDS-1179: --- I won't get to this until after Wednesday next week. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15494526#comment-15494526 ] Zack Shoylev commented on JCLOUDS-1179: --- Ah, nice catch. I'll look into it. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent
[
https://issues.apache.org/jira/browse/JCLOUDS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15494392#comment-15494392
]
Zack Shoylev commented on JCLOUDS-1176:
---
I am noticing that we already have a deleteObjectNotFound integration test in
blobstore?
> Swift delete operation is not idempotent
>
>
> Key: JCLOUDS-1176
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1176
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: Vijay Panghal
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> Openstack Swift delete operation used to be idempotent. But after this pull
> request https://github.com/jclouds/jclouds/pull/700
> second delete is failing with these stack trace
> {quote}
> org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed
> connecting to DELETE
> https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f
> HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy67.removeObject(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> at com.sun.proxy.$Proxy69.removeBlob(Unknown Source)
> at
> com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent
[
https://issues.apache.org/jira/browse/JCLOUDS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486872#comment-15486872
]
Zack Shoylev commented on JCLOUDS-1176:
---
I'll have a look.
> Swift delete operation is not idempotent
>
>
> Key: JCLOUDS-1176
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1176
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: Vijay Panghal
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> Openstack Swift delete operation used to be idempotent. But after this pull
> request https://github.com/jclouds/jclouds/pull/700
> second delete is failing with these stack trace
> {quote}
> org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed
> connecting to DELETE
> https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f
> HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy67.removeObject(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> at com.sun.proxy.$Proxy69.removeBlob(Unknown Source)
> at
> com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Commented] (JCLOUDS-1160) Consider gson 2.7 upgrade
[ https://issues.apache.org/jira/browse/JCLOUDS-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447219#comment-15447219 ] Zack Shoylev commented on JCLOUDS-1160: --- > It also includes an improvement to the @SerializedName annotation that makes > it work with AutoValue. This is great news, and it doesn't seem to hurt anything else. +1 to get this in before 2.0 > Consider gson 2.7 upgrade > - > > Key: JCLOUDS-1160 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1160 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 1.9.0 >Reporter: Andrew Gaul > > An S3Proxy user complained about not being able to include it in his > application with a Spring Boot 1.4 dependency due to gson conflicts: > https://github.com/andrewgaul/s3proxy/issues/148 > https://github.com/spring-projects/spring-boot/issues/6761 > We should consider upgrading to gson 2.7 in master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1126) Jclouds needs to use either legacy compute or update validation to account for 2.1 API
[
https://issues.apache.org/jira/browse/JCLOUDS-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev resolved JCLOUDS-1126.
---
Resolution: Fixed
Fix Version/s: 2.0.0
1.9.
https://github.com/jclouds/jclouds/pull/974
> Jclouds needs to use either legacy compute or update validation to account
> for 2.1 API
> --
>
> Key: JCLOUDS-1126
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1126
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 1.9.2
> Environment: Openstack Liberty+
>Reporter: Arvind Nadendla
>Priority: Minor
> Fix For: 1.9., 2.0.0
>
>
> As part of Openstack releases(Kilo+), V2.1 of the API's are being exposed.
> 2.1 supports stronger input validation. see here
> Another impact is strong input validation of JSON-Schema. JSON-Schema
> contains the “additionalProperties” feature which can deny undefined
> properties in an input request. V2 API just ignored undefined properties if a
> request contain, but V2.1 API denies the request and returns a BadRequest
> response to a client.
> During V2.1 development, we found that Tempest also passed undefined
> properties to Nova API, and Nova V2 API just ignored them then tests
> succeeded. However Nova V2.1 API rejected these requests and tests failed. So
> that was Tempest bug, but we imagined this kind of problem would happen on
> the other SDKs. Before fixing this Tempest bug, we investigated major
> SDKs(fog, jclouds)’s code and we confirmed these SDKs send a valid request
> without undefined properties and they don’t contain this kind of problem.
> For creating flavors in openstack, Jcloud includes the links properties which
> were safely ignored in V2 API but causing issues in V2.1 API
> Jclouds needs to use either legacy compute URL or update validation to
> account for 2.1 API.
> I see this as a general problem, not sure why the tests are not failing to
> indicate this problem
> POST http://172.19.46.39:8774/v2.1/8d0578a052814946b2115e72a026bf44/flavors
> HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content:
> [{"badRequest": {"message": "Invalid input for field/attribute flavor. Value:
> {u'name':
> u'SNORT-0.2-0.2.0.20150626002613-IPS-1-snort_disk-20150626002613.qcow2',
> u'links': [], u'ram': 2048, u'vcpus': 2, u'disk': 50, u'id':
> u'IPS-1_RegionOne'}. Additional properties are not allowed (u'links' was
> unexpected)", "code": 400}}]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1129) Add more interfaces of the same network
[
https://issues.apache.org/jira/browse/JCLOUDS-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15334001#comment-15334001
]
Zack Shoylev commented on JCLOUDS-1129:
---
Can you make a PR with what you have for now and link it here? It will be
easier to discuss with code.
>From what I am seeing you would have to change this
>https://github.com/jclouds/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/options/CreateServerOptions.java#L108
> which is the actual implementation of how the options are bound. Also this:
>https://github.com/jclouds/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/options/CreateServerOptions.java#L226
> Add more interfaces of the same network
> ---
>
> Key: JCLOUDS-1129
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1129
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-compute
>Affects Versions: 1.9.2, 2.0.0
> Environment: Ubuntu 14.04
>Reporter: Urban Zaletel
>
> When I create a new VM, i would like to add more interfaces from the same
> network, but because implementation uses ImmutableSet instead of List, only
> the distinct ones are preserved.
> public CreateServerOptions networks(Iterable networks) {
> this.networks = ImmutableSet.copyOf(networks);
> return this;
> }
> I can achive the desired with heat, providing the same networks:
> cirros-one-to-four:
> type: OS::Nova::Server
> properties:
> availability_zone: nova
> flavor: m1.tiny
> image: TestVM
> networks:
> - network: lkra-mgmt-1
> - network: lkra-mgmt-2
> - network: lkra-mgmt-2
> - network: lkra-mgmt-2
> user_data_format: RAW
> user_data: |
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1123) openstack-swift updateTemporaryUrlKey problems
[ https://issues.apache.org/jira/browse/JCLOUDS-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-1123. --- Resolution: Fixed Added a live test as well as tested and working examples for how to update the signed URLs key. > openstack-swift updateTemporaryUrlKey problems > -- > > Key: JCLOUDS-1123 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1123 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.0.0 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > > Add an openstack-swift live test for `updateTemporaryUrlKey` and figure out > why it is failing with Rackspace. It should be a simple metadata update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1123) openstack-swift updateTemporaryUrlKey problems
[ https://issues.apache.org/jira/browse/JCLOUDS-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15317249#comment-15317249 ] Zack Shoylev commented on JCLOUDS-1123: --- https://github.com/jclouds/jclouds-examples/pull/87 > openstack-swift updateTemporaryUrlKey problems > -- > > Key: JCLOUDS-1123 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1123 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.0.0 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > > Add an openstack-swift live test for `updateTemporaryUrlKey` and figure out > why it is failing with Rackspace. It should be a simple metadata update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1123) openstack-swift updateTemporaryUrlKey problems
[ https://issues.apache.org/jira/browse/JCLOUDS-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15317232#comment-15317232 ] Zack Shoylev commented on JCLOUDS-1123: --- https://github.com/jclouds/jclouds/pull/965 > openstack-swift updateTemporaryUrlKey problems > -- > > Key: JCLOUDS-1123 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1123 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.0.0 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > > Add an openstack-swift live test for `updateTemporaryUrlKey` and figure out > why it is failing with Rackspace. It should be a simple metadata update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCLOUDS-1123) openstack-swift updateTemporaryUrlKey problems
Zack Shoylev created JCLOUDS-1123: - Summary: openstack-swift updateTemporaryUrlKey problems Key: JCLOUDS-1123 URL: https://issues.apache.org/jira/browse/JCLOUDS-1123 Project: jclouds Issue Type: Bug Components: jclouds-blobstore Affects Versions: 2.0.0 Reporter: Zack Shoylev Assignee: Zack Shoylev Priority: Minor Add an openstack-swift live test for `updateTemporaryUrlKey` and figure out why it is failing with Rackspace. It should be a simple metadata update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1095) Update OpenStack KeyStone Support for Zaqar
[ https://issues.apache.org/jira/browse/JCLOUDS-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15200099#comment-15200099 ] Zack Shoylev commented on JCLOUDS-1095: --- Quite a few issues were fixed in 2.0.0-SNAPSHOT ; It is broken in 1.9.2 though. Have you tried testing with snapshot? > Update OpenStack KeyStone Support for Zaqar > --- > > Key: JCLOUDS-1095 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1095 > Project: jclouds > Issue Type: Sub-task > Components: jclouds-core >Affects Versions: 1.9.2 > Environment: All supported environments >Reporter: Fernando Ribeiro >Priority: Minor > > jclouds doesn't work with newer OpenStack Liberty because KeyStone support > wasn't updated when Marconi was renamed to Zaqar [1]. > [1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041528.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144860#comment-15144860
]
Zack Shoylev commented on JCLOUDS-1064:
---
More questions:
1. If you omit specifying the .contentLength(payload.size()) in your code, does
it still timeout as described?
2. If you set custom timeout settings, such as
Properties overrides = new Properties();
// Retry after 25 seconds of no response
overrides.setProperty(Constants.PROPERTY_SO_TIMEOUT, "25000");
// Keep retrying indefinitely
overrides.setProperty(Constants.PROPERTY_MAX_RETRIES,
String.valueOf(Integer.MAX_VALUE));
// Do not wait between retries
overrides.setProperty(Constants.PROPERTY_RETRY_DELAY_START , "0");
do you get different results? You can experiment with these a bit to see if you
get more stable behavior or a speed-up. Post some logs if you get different
results.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143308#comment-15143308
]
Zack Shoylev commented on JCLOUDS-1064:
---
To clarify this a bit, which version of java are you using? It's strange to see
a read timeout when the swift commandline is working fine.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15143337#comment-15143337
]
Zack Shoylev commented on JCLOUDS-1064:
---
Is this reproducible with the latest java 8? I am asking so we can more easily
isolate to jclouds or the service, and because of bugs like
http://bugs.java.com/view_bug.do?bug_id=8012625 (which might not even be
relevant here).
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128747#comment-15128747
]
Zack Shoylev commented on JCLOUDS-1064:
---
Do you have the wire logs where the PUT operation (uploading the file) happened?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128179#comment-15128179
]
Zack Shoylev commented on JCLOUDS-1064:
---
What are the wire logs like with this version of the code?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126966#comment-15126966
]
Zack Shoylev commented on JCLOUDS-1064:
---
I think that's a good idea.
[~rgojji] - can you add something like:
Properties overrides = new Properties();
overrides.setProperty("jclouds.strip-expect-header", "true" );
to your overrides? I'm interested to see if it will work, as this is my best
guess as to what is going wrong.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123482#comment-15123482
]
Zack Shoylev commented on JCLOUDS-1064:
---
[~gaul] Any ideas on this problem I described above? I have a test, but I am
not sure it's properly replicating the issue.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121871#comment-15121871
]
Zack Shoylev commented on JCLOUDS-1064:
---
The timestamp between the two logs differs by about 2 days. Is this the same
run? I see a single successful PUT, and it's not what I would expect based on
the jclouds.log content (multiple PUTs, one unfinished).
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123082#comment-15123082
]
Zack Shoylev commented on JCLOUDS-1064:
---
I think I was able to reproduce this. I need to double-check some more, but I
think jclouds is having issues handling the 100 Continue response, which is
expected before the 200 OK response from the server. At least in my test cases.
This will require further investigation to fix, though, as I was pretty sure
100 Continue was handled automatically.
Test case I am using: https://gist.github.com/zack-shoylev/de460bd84041e7db44aa
Results in null etag returned. Logging has:
2016-01-29 00:44:09,088 DEBUG [jclouds.headers] [pool-1-thread-1] >> POST
http://localhost:62342/tokens HTTP/1.1
2016-01-29 00:44:09,088 DEBUG [jclouds.headers] [pool-1-thread-1] >> Accept:
application/json
2016-01-29 00:44:09,088 DEBUG [jclouds.headers] [pool-1-thread-1] >>
Content-Type: application/json
2016-01-29 00:44:09,088 DEBUG [jclouds.headers] [pool-1-thread-1] >>
Content-Length: 95
2016-01-29 00:44:09,102 DEBUG [jclouds.headers] [pool-1-thread-1] << HTTP/1.1
200 OK
2016-01-29 00:44:09,102 DEBUG [jclouds.headers] [pool-1-thread-1] << Accept:
application/json
2016-01-29 00:44:09,103 DEBUG [jclouds.headers] [pool-1-thread-1] <<
Content-Type: application/unknown
2016-01-29 00:44:09,103 DEBUG [jclouds.headers] [pool-1-thread-1] <<
Content-Length: 9871
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >> PUT
http://localhost:62342/v1/MossoCloudFS_5bcf396e-39dd-45ff-93a1-712b9aba90a9/myContainer/myObject
HTTP/1.1
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >> Expect:
100-continue
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >> Accept:
application/json
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >>
X-Object-Meta-apiname: swift
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >>
X-Object-Meta-apiversion: v1.1
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >>
Transfer-Encoding: chunked
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >>
X-Auth-Token: bb03a23aa8271291a7aaa9aaa2aa
2016-01-29 00:44:09,141 DEBUG [jclouds.headers] [pool-1-thread-1] >>
Content-Type: application/unknown
2016-01-29 00:44:09,144 DEBUG [jclouds.headers] [pool-1-thread-1] << HTTP/1.1
100 Continue
2016-01-29 00:44:09,144 DEBUG [jclouds.headers] [pool-1-thread-1] <<
Content-Type: application/unknown
2016-01-29 00:44:09,144 DEBUG [jclouds.headers] [pool-1-thread-1] <<
Content-Length: 0
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122588#comment-15122588
]
Zack Shoylev commented on JCLOUDS-1064:
---
It's strange that this wire log has a single successful PUT, while one of the
previous wire logs had multiple PUTs (multiple PUTs are of course what we
should expect).
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122622#comment-15122622
]
Zack Shoylev commented on JCLOUDS-1064:
---
I am trying to get this reproduced in a test. One way this can be streamlined
is if you can make a small project replicating the problem against a vanilla
devstack instance (that might not be possible, especially if your service is
behaving slightly differently than expected)?
Otherwise I have to rely on the logs, but I don't see anything too problematic
in those, aside from some inconsistencies. And I am not very sure why the PUT
would return a null etag, but I am working on it.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121438#comment-15121438
]
Zack Shoylev commented on JCLOUDS-1064:
---
Do you have the wire log from that last run? Almost seems like the last 200 OK
response got cut off or interrupted somehow?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118198#comment-15118198
]
Zack Shoylev commented on JCLOUDS-1064:
---
Is there more to the log? If I remember correctly, there should be multiple
PUTs for each part, and then a PUT for the manifest of the multipart-upload. At
least one of the PUTs should be failing with a missing etag or null etag or
some kind of error (this is where the NPE should be coming from).
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118385#comment-15118385
]
Zack Shoylev commented on JCLOUDS-1064:
---
Hm, no, the null pointer exception happens when the regular (one single part)
PUT upload returns a null etag somehow (even though the log has an Etag in the
response). Using the log you provided, I have not been able to reproduce this.
Another question for your code: it should be sufficient to supply just the
file, you shouldn't have to supply md5 or length. The example we use usually
just has something like:
Blob blob =
blobStore.blobBuilder(objectName).payload(Files.asByteSource(input))
.contentType(MediaType.APPLICATION_OCTET_STREAM).contentDisposition(objectName).build();
(from here:
https://github.com/jclouds/jclouds-examples/blob/master/blobstore-largeblob/src/main/java/org/jclouds/examples/blobstore/largeblob/MainApp.java)
I will try a few more things, but can you modify your code to be closer to the
example code and see if this still happens?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118385#comment-15118385
]
Zack Shoylev edited comment on JCLOUDS-1064 at 1/27/16 1:02 AM:
Hm, no, the null pointer exception happens when the regular (one single part)
PUT upload returns a null etag somehow (even though the log has an Etag in the
response). Using the log you provided, I have not been able to reproduce this.
Another question for your code: it should be sufficient to supply just the
file, you shouldn't have to supply md5 or length. The example we use:
Blob blob =
blobStore.blobBuilder(objectName).payload(Files.asByteSource(input))
.contentType(MediaType.APPLICATION_OCTET_STREAM).contentDisposition(objectName).build();
(from here:
https://github.com/jclouds/jclouds-examples/blob/master/blobstore-largeblob/src/main/java/org/jclouds/examples/blobstore/largeblob/MainApp.java)
I will try a few more things, but can you modify your code to be closer to the
example code and see if this still happens?
was (Author: zack-s):
Hm, no, the null pointer exception happens when the regular (one single part)
PUT upload returns a null etag somehow (even though the log has an Etag in the
response). Using the log you provided, I have not been able to reproduce this.
Another question for your code: it should be sufficient to supply just the
file, you shouldn't have to supply md5 or length. The example we use usually
just has something like:
Blob blob =
blobStore.blobBuilder(objectName).payload(Files.asByteSource(input))
.contentType(MediaType.APPLICATION_OCTET_STREAM).contentDisposition(objectName).build();
(from here:
https://github.com/jclouds/jclouds-examples/blob/master/blobstore-largeblob/src/main/java/org/jclouds/examples/blobstore/largeblob/MainApp.java)
I will try a few more things, but can you modify your code to be closer to the
example code and see if this still happens?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118397#comment-15118397
]
Zack Shoylev commented on JCLOUDS-1064:
---
Is the log the same in this second version of the code?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118472#comment-15118472
]
Zack Shoylev commented on JCLOUDS-1064:
---
Which version of jclouds, 1.9.2 or master?
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115972#comment-15115972
]
Zack Shoylev commented on JCLOUDS-1064:
---
Any chance you can get us some (redacted) info from the jclouds wire log?
https://jclouds.apache.org/reference/logging/
I am specifically interested in seeing what the service returns as a response
for the chunk that fails.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116287#comment-15116287
]
Zack Shoylev commented on JCLOUDS-1064:
---
Thanks! This is very helpful. This shows that the request for uploading one of
the parts was failed by the swift service after some retries. Now, in this
case, this didn't seem to result in a NPE? Was something different?
As for the 502 itself. Smaller parts and more retries / more backoff between
retries might help, as you might be overloading your swift provider.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> {code:java}
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> {code}
> Exception Stacktrace:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1530#comment-1530
]
Zack Shoylev commented on JCLOUDS-1064:
---
String eTag = api.getObjectApi(regionId, mpu.containerName()).put(partName,
payload);
long partSize = payload.getContentMetadata().getContentLength();
return MultipartPart.create(partNumber, partSize, eTag);
It seems the etag returned by the put is null, which likely means the upload
(for that specific part) failed.
uploadMultipartPart should probably be more resilient? And avoid throwing an
exception in favor or returning a null etag from putMultipartBlob on fail.
[~gaul], are you working on this? Or do you want me to have a look.
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> Exception Stacktrace:
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> Please help.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag
[
https://issues.apache.org/jira/browse/JCLOUDS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev reassigned JCLOUDS-1064:
-
Assignee: Zack Shoylev
> multipart upload throwing : NullPointerException: Null partETag
> ---
>
> Key: JCLOUDS-1064
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1064
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.0.0
> Environment: openstack-swift, using jclouds 2.0
>Reporter: Ramesh Gojji
>Assignee: Zack Shoylev
>
> I am trying to upload a file in chunks to the openstack-swift. Here is the
> snippet of the code I am using to upload a file named dom4j-1.6.1.jar in
> chunks.
> blobStore.putBlob("jclouds-example", blob) does work, but if I add multipart
> to the method, then I get NullPointerException: Null partETag.
> ByteSource payload = Files.asByteSource(tempFile);
> Blob blob = blobStore.blobBuilder(objectName)
> .payload(payload)
> .contentDisposition("attachment; filename=dom4j-1.6.1.jar")
> .contentMD5(payload.hash(Hashing.md5()))
> .contentLength(payload.size())
> .contentType(MediaType.OCTET_STREAM.toString())
> .build();
> System.out.println(blob.getMetadata().getName());
> // Upload the Blob
> String eTag = blobStore.putBlob("jclouds-example", blob,
> multipart());
> Exception Stacktrace:
> Exception in thread "main" java.lang.NullPointerException: Null partETag
> at
> org.jclouds.blobstore.domain.AutoValue_MultipartPart.(AutoValue_MultipartPart.java:20)
> at
> org.jclouds.blobstore.domain.MultipartPart.create(MultipartPart.java:29)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.uploadMultipartPart(RegionScopedSwiftBlobStore.java:481)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putMultipartBlob(RegionScopedSwiftBlobStore.java:567)
> at
> org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.putBlob(RegionScopedSwiftBlobStore.java:244)
> at JCloudTest.(JCloudTest.java:75)
> at JCloudTest.main(JCloudTest.java:26)
> Please help.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCLOUDS-1055) BlobStore.blobExists throws exception when blob does not exist
[
https://issues.apache.org/jira/browse/JCLOUDS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev closed JCLOUDS-1055.
-
Resolution: Not A Problem
Service side API seems to not behave as expected in the logs provided.
> BlobStore.blobExists throws exception when blob does not exist
> --
>
> Key: JCLOUDS-1055
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1055
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 1.9.1
> Environment: Operating System Version: Ubuntu 14.04
> Cloud and API Version: Ceph 0.94, Rados 0.94
> java version "1.7.0_91"
>Reporter: Giorgi Kikolashvili
>Assignee: Zack Shoylev
>Priority: Minor
> Labels: openstack-swift
>
> I get exeption when I try to call {{blobExits(container, name)}} with valid
> container and invalid name. Jclouds
> [javadoc|https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/blobstore/BlobStore.html#blobExists(java.lang.String,
> java.lang.String)] does not document this behavior.
> stacktrace:
> {code}
> org.jclouds.http.HttpResponseException: request: HEAD
> http://swift.ceph.myhost/swift/v1/gkikolashvili-2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
> HTTP/1.1 failed with response: HTTP/1.1 404 Not Found
> at
> org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:55)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:67)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:180)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:150)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:129)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:95)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:56)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy132.objectExists(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.blobExists(SwiftBlobStore.java:163)
> at nbs.core.SwiftClient.blobExits(SwiftClient.java:97)
> at nbs.core.SwiftClient.get(SwiftClient.java:58)
> at nbs.service.v3.BlobService.download(BlobService.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> at
> org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
> at
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
> at
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
>
[jira] [Commented] (JCLOUDS-920) org.jclouds.openstack.keystone.v2_0.domain.User.getTenantId() method does not return valid tenant id for user
[
https://issues.apache.org/jira/browse/JCLOUDS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106946#comment-15106946
]
Zack Shoylev commented on JCLOUDS-920:
--
I thought that was fixed in master, btw.
> org.jclouds.openstack.keystone.v2_0.domain.User.getTenantId() method does not
> return valid tenant id for user
> -
>
> Key: JCLOUDS-920
> URL: https://issues.apache.org/jira/browse/JCLOUDS-920
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.0
> Environment: OS version: Ubuntu 14.01
> Java version: java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxa6470sr8fp10-20141219_01(SR8 FP10))
> IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References
> 20141216_227497 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR8_20141216_0955_B227497
> JIT - r11.b07_20141003_74578.05
> GC - R26_Java726_SR8_20141216_0955_B227497_CMPRSS
> J9CL - 20141216_227497)
> JCL - 20141217_01 based on Oracle jdk7u75-b12
>Reporter: Arunagiri
>
> jclouds.wire prints tenant id associated with that user, but when I iterate
> users list and print them individually, it is missing.
> 18:28:23.994 [main] DEBUG jclouds.wire - << "{"users": [{"username": "admin",
> "name": "admin", "id": "0bdf72cbe5294340b4df6ba137ec1f0d", "enabled": true,
> "email": null, "tenantId": "180ff309a56f489d9746c1c12670c10b"}, {"username":
> "swift", "name": "swift", "enabled": true, "email": null, "id":
> "3805eb0004094ed6a3499b61969d2dd1"}, {"username": "newUser", "name":
> "newUser", "enabled": true, "email": "new.em...@example.com", "tenant":
> "22d34e93b3d54753b99ec5f6052ba578", "id":
> "43a124f9f4b44f978e23989936480c16"}, {"username": "demo", "name": "demo",
> "enabled": true, "email": null, "id": "4692e31da0cc456786390db6688ccde6"},
> {"username": "tester", "name": "tester", "enabled": true, "email": null,
> "id": "ba19e0977f4c45e19e88c122e30e652b"}]}"
> Tenant{id=180ff309a56f489d9746c1c12670c10b, name=admin, description=admin
> Tenant, enabled=true}
> User{id=43a124f9f4b44f978e23989936480c16, name=newUser,
> email=new.em...@example.com, enabled=true, roles=[]}
> From the above log statements, one can see that the tenant id
> (22d34e93b3d54753b99ec5f6052ba578) is printed inside jclouds.wire and is
> missing in the second line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCLOUDS-1055) BlobStore.blobExists throws exception when blob does not exist
[
https://issues.apache.org/jira/browse/JCLOUDS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097019#comment-15097019
]
Zack Shoylev edited comment on JCLOUDS-1055 at 1/13/16 9:23 PM:
Ok.
When the 404 hits, the ParseSwiftErrorFromHttpResponse parser tries to match
the path
/v1/2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
to
^/v[0-9][^/]*/[^/]+/([^/]+)/(.*)
~= /v1/something/container/key
Because "something" is missing (in unit tests, that's 'AUTH_test', the parser
fails and throws a generic 404 exception instead of returning false.
was (Author: zack-s):
Ok.
When the 404 hits, the ParseSwiftErrorFromHttpResponse parser tries to match
the path
/v1/2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
to
^/v[0-9][^/]*/[^/]+/([^/]+)/(.*)
(~= /v1/something/container/key
Because "something" is missing (in unit tests, that's 'AUTH_test', the parser
fails and throws a generic 404 exception instead of returning false.
> BlobStore.blobExists throws exception when blob does not exist
> --
>
> Key: JCLOUDS-1055
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1055
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 1.9.1
> Environment: Operating System Version: Ubuntu 14.04
> Cloud and API Version: Ceph 0.94, Rados 0.94
> java version "1.7.0_91"
>Reporter: Giorgi Kikolashvili
>Assignee: Zack Shoylev
>Priority: Minor
> Labels: openstack-swift
>
> I get exeption when I try to call {{blobExits(container, name)}} with valid
> container and invalid name. Jclouds
> [javadoc|https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/blobstore/BlobStore.html#blobExists(java.lang.String,
> java.lang.String)] does not document this behavior.
> stacktrace:
> {code}
> org.jclouds.http.HttpResponseException: request: HEAD
> http://swift.ceph.myhost/swift/v1/gkikolashvili-2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
> HTTP/1.1 failed with response: HTTP/1.1 404 Not Found
> at
> org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:55)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:67)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:180)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:150)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:129)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:95)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:56)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy132.objectExists(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.blobExists(SwiftBlobStore.java:163)
> at nbs.core.SwiftClient.blobExits(SwiftClient.java:97)
> at nbs.core.SwiftClient.get(SwiftClient.java:58)
> at nbs.service.v3.BlobService.download(BlobService.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
> at
>
[jira] [Commented] (JCLOUDS-1055) BlobStore.blobExists throws exception when blob does not exist
[
https://issues.apache.org/jira/browse/JCLOUDS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097019#comment-15097019
]
Zack Shoylev commented on JCLOUDS-1055:
---
Ok.
When the 404 hits, the ParseSwiftErrorFromHttpResponse parser tries to match
the path
/v1/2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
to
^/v[0-9][^/]*/[^/]+/([^/]+)/(.*)
(~= /v1/something/container/key
Because "something" is missing (in unit tests, that's 'AUTH_test', the parser
fails and throws a generic 404 exception instead of returning false.
> BlobStore.blobExists throws exception when blob does not exist
> --
>
> Key: JCLOUDS-1055
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1055
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 1.9.1
> Environment: Operating System Version: Ubuntu 14.04
> Cloud and API Version: Ceph 0.94, Rados 0.94
> java version "1.7.0_91"
>Reporter: Giorgi Kikolashvili
>Assignee: Zack Shoylev
>Priority: Minor
> Labels: openstack-swift
>
> I get exeption when I try to call {{blobExits(container, name)}} with valid
> container and invalid name. Jclouds
> [javadoc|https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/blobstore/BlobStore.html#blobExists(java.lang.String,
> java.lang.String)] does not document this behavior.
> stacktrace:
> {code}
> org.jclouds.http.HttpResponseException: request: HEAD
> http://swift.ceph.myhost/swift/v1/gkikolashvili-2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
> HTTP/1.1 failed with response: HTTP/1.1 404 Not Found
> at
> org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:55)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:67)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:180)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:150)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:129)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:95)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:56)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy132.objectExists(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.blobExists(SwiftBlobStore.java:163)
> at nbs.core.SwiftClient.blobExits(SwiftClient.java:97)
> at nbs.core.SwiftClient.get(SwiftClient.java:58)
> at nbs.service.v3.BlobService.download(BlobService.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> at
> org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> at
[jira] [Comment Edited] (JCLOUDS-1055) BlobStore.blobExists throws exception when blob does not exist
[
https://issues.apache.org/jira/browse/JCLOUDS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097019#comment-15097019
]
Zack Shoylev edited comment on JCLOUDS-1055 at 1/13/16 9:30 PM:
Ok.
When the 404 hits, the ParseSwiftErrorFromHttpResponse parser tries to match
the path
/v1/2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
to
^/v[0-9][^/]*/[^/]+/([^/]+)/(.*)
~= /v1/something/container/key
Because "something" is missing (in unit tests, that's 'AUTH_test', the parser
fails and throws a generic 404 exception instead of returning false.
And to clarify, that "something" is supposed to be the account string.
http://developer.openstack.org/api-ref-objectstorage-v1.html
As such, this does not seem like a bug to me; the service-side API appears to
not conform to expectations?
was (Author: zack-s):
Ok.
When the 404 hits, the ParseSwiftErrorFromHttpResponse parser tries to match
the path
/v1/2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
to
^/v[0-9][^/]*/[^/]+/([^/]+)/(.*)
~= /v1/something/container/key
Because "something" is missing (in unit tests, that's 'AUTH_test', the parser
fails and throws a generic 404 exception instead of returning false.
> BlobStore.blobExists throws exception when blob does not exist
> --
>
> Key: JCLOUDS-1055
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1055
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 1.9.1
> Environment: Operating System Version: Ubuntu 14.04
> Cloud and API Version: Ceph 0.94, Rados 0.94
> java version "1.7.0_91"
>Reporter: Giorgi Kikolashvili
>Assignee: Zack Shoylev
>Priority: Minor
> Labels: openstack-swift
>
> I get exeption when I try to call {{blobExits(container, name)}} with valid
> container and invalid name. Jclouds
> [javadoc|https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/blobstore/BlobStore.html#blobExists(java.lang.String,
> java.lang.String)] does not document this behavior.
> stacktrace:
> {code}
> org.jclouds.http.HttpResponseException: request: HEAD
> http://swift.ceph.myhost/swift/v1/gkikolashvili-2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
> HTTP/1.1 failed with response: HTTP/1.1 404 Not Found
> at
> org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:55)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:67)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:180)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:150)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:129)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:95)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:56)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy132.objectExists(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.blobExists(SwiftBlobStore.java:163)
> at nbs.core.SwiftClient.blobExits(SwiftClient.java:97)
> at nbs.core.SwiftClient.get(SwiftClient.java:58)
> at nbs.service.v3.BlobService.download(BlobService.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
>
[jira] [Assigned] (JCLOUDS-1055) BlobStore.blobExists throws exception when blob does not exist
[
https://issues.apache.org/jira/browse/JCLOUDS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev reassigned JCLOUDS-1055:
-
Assignee: Zack Shoylev
> BlobStore.blobExists throws exception when blob does not exist
> --
>
> Key: JCLOUDS-1055
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1055
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 1.9.1
> Environment: Operating System Version: Ubuntu 14.04
> Cloud and API Version: Ceph 0.94, Rados 0.94
> java version "1.7.0_91"
>Reporter: Giorgi Kikolashvili
>Assignee: Zack Shoylev
>Priority: Minor
>
> I get exeption when I try to call {{blobExits(container, name)}} with valid
> container and invalid name. Jclouds
> [javadoc|https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/blobstore/BlobStore.html#blobExists(java.lang.String,
> java.lang.String)] does not document this behavior.
> stacktrace:
> {code}
> org.jclouds.http.HttpResponseException: request: HEAD
> http://swift.ceph.myhost/swift/v1/gkikolashvili-2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
> HTTP/1.1 failed with response: HTTP/1.1 404 Not Found
> at
> org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:55)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:67)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:180)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:150)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:129)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:95)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:56)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy132.objectExists(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.blobExists(SwiftBlobStore.java:163)
> at nbs.core.SwiftClient.blobExits(SwiftClient.java:97)
> at nbs.core.SwiftClient.get(SwiftClient.java:58)
> at nbs.service.v3.BlobService.download(BlobService.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> at
> org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
> at
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
> at
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
> at
> org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
>
[jira] [Commented] (JCLOUDS-1055) BlobStore.blobExists throws exception when blob does not exist
[
https://issues.apache.org/jira/browse/JCLOUDS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15095221#comment-15095221
]
Zack Shoylev commented on JCLOUDS-1055:
---
I am looking into it.
> BlobStore.blobExists throws exception when blob does not exist
> --
>
> Key: JCLOUDS-1055
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1055
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 1.9.1
> Environment: Operating System Version: Ubuntu 14.04
> Cloud and API Version: Ceph 0.94, Rados 0.94
> java version "1.7.0_91"
>Reporter: Giorgi Kikolashvili
>Assignee: Zack Shoylev
>Priority: Minor
>
> I get exeption when I try to call {{blobExits(container, name)}} with valid
> container and invalid name. Jclouds
> [javadoc|https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/blobstore/BlobStore.html#blobExists(java.lang.String,
> java.lang.String)] does not document this behavior.
> stacktrace:
> {code}
> org.jclouds.http.HttpResponseException: request: HEAD
> http://swift.ceph.myhost/swift/v1/gkikolashvili-2016-01-12/1cfeb966569703dcdba64354ee5a-fb66d02f-f2a4-4a4b-90a9-1106b66a014aa
> HTTP/1.1 failed with response: HTTP/1.1 404 Not Found
> at
> org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:55)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:67)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:180)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:150)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:129)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:95)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:56)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy132.objectExists(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.blobExists(SwiftBlobStore.java:163)
> at nbs.core.SwiftClient.blobExits(SwiftClient.java:97)
> at nbs.core.SwiftClient.get(SwiftClient.java:58)
> at nbs.service.v3.BlobService.download(BlobService.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> at
> org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
> at
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
> at
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
> at
>
[jira] [Resolved] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
[
https://issues.apache.org/jira/browse/JCLOUDS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev resolved JCLOUDS-1013.
---
Resolution: Fixed
Fix Version/s: (was: 1.9.2)
2.0.0
> Cannot find FloatingIPAPI nova extension against devstack
> -
>
> Key: JCLOUDS-1013
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Zack Shoylev
>Assignee: Zack Shoylev
> Fix For: 2.0.0
>
>
> Using devstack
> Nova API not returning FloatingIPApi even though the ExtensionApi was listing
> "os-floating-ips".
> Upon inspection, it is found out that the namespace for this extension is
> changed to a fake xml.
> Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
> namespace=http://docs.openstack.org/compute/ext/fake_xml,
> alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
> description=Floating IPs support.}
> (notice fake_xml in the namespace URI)
> However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
> listing it with the previous namespace:
> //Floating IPs support
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> Similar issue:
> http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
> https://github.com/jclouds/jclouds/pull/813
> Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py
> :
> # V2.1 does not support XML but we need to keep an entry in the # /extensions
> information returned to the user for backwards # compatibility FAKE_XML_URL =
> "http://docs.openstack.org/compute/ext/fake_xml;
> After changing the extension namespace in ExtensionNamespaces.java, I was
> able to make it work.
>//Floating IPs support
>//public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/compute/ext/fake_xml;;
> All extensions are returning the fake xml namespace.
> So, all of them would fail lookup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
[
https://issues.apache.org/jira/browse/JCLOUDS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15042121#comment-15042121
]
Zack Shoylev commented on JCLOUDS-1013:
---
https://github.com/jclouds/jclouds/pull/889
Names will have to be added to the extensions as well in separate PR.
> Cannot find FloatingIPAPI nova extension against devstack
> -
>
> Key: JCLOUDS-1013
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Zack Shoylev
>Assignee: Zack Shoylev
> Fix For: 1.9.2
>
>
> Using devstack
> Nova API not returning FloatingIPApi even though the ExtensionApi was listing
> "os-floating-ips".
> Upon inspection, it is found out that the namespace for this extension is
> changed to a fake xml.
> Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
> namespace=http://docs.openstack.org/compute/ext/fake_xml,
> alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
> description=Floating IPs support.}
> (notice fake_xml in the namespace URI)
> However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
> listing it with the previous namespace:
> //Floating IPs support
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> Similar issue:
> http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
> https://github.com/jclouds/jclouds/pull/813
> Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py
> :
> # V2.1 does not support XML but we need to keep an entry in the # /extensions
> information returned to the user for backwards # compatibility FAKE_XML_URL =
> "http://docs.openstack.org/compute/ext/fake_xml;
> After changing the extension namespace in ExtensionNamespaces.java, I was
> able to make it work.
>//Floating IPs support
>//public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/compute/ext/fake_xml;;
> All extensions are returning the fake xml namespace.
> So, all of them would fail lookup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1015) BlobStore.putBlob throws RuntimeException with filesystem provider on localized Windows
[ https://issues.apache.org/jira/browse/JCLOUDS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-1015. --- Resolution: Fixed > BlobStore.putBlob throws RuntimeException with filesystem provider on > localized Windows > --- > > Key: JCLOUDS-1015 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1015 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.1 > Environment: Microsoft Windows (tested on 7 and 10), Java 7 and 8. >Reporter: Halvdan Hoem Grelland >Assignee: Zack Shoylev >Priority: Minor > Labels: filesystem, windows > > When using the filesystem provider on a localized Windows system putBlob > consistenly throws a RuntimeException. The put operation does succeed, > however, meaning a viable workaround is to catch-and-ignore. > The cause of the Exception is a UserPrincipalNotFoundException which is > thrown in org.jclouds.filesystem.util.Utils while trying to resolve the > Windows 'Everyone' user group using > UserPrincipalLookupService.lookupPrincipalByName. > Turns out the 'Everyone' group/user is only actually available on Windows > systems set to an English locale, whilst other locales will likely have > localized names for the group (tested on Norwegian Windows in which the > Everyone group is known as "Alle"). > The only ubiquitous reference to any of the built-in groups or users on a > Windows system are the SIDs. For example, 'Everyone' is known as 'S-1-1-0'. > Unfortunately, the API exposed in java.nio.file doesn't accept SIDs for > lookup, meaning there is, as far as I can tell, no pure Java solution to > resolving the UserPrincipal without knowing the (localized) name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1015) BlobStore.putBlob throws RuntimeException with filesystem provider on localized Windows
[ https://issues.apache.org/jira/browse/JCLOUDS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022180#comment-15022180 ] Zack Shoylev commented on JCLOUDS-1015: --- https://github.com/jclouds/jclouds/commit/2efcb2c5a9fadc52bcac411898154735eea4a66a Should fix this. > BlobStore.putBlob throws RuntimeException with filesystem provider on > localized Windows > --- > > Key: JCLOUDS-1015 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1015 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.1 > Environment: Microsoft Windows (tested on 7 and 10), Java 7 and 8. >Reporter: Halvdan Hoem Grelland >Assignee: Zack Shoylev >Priority: Minor > Labels: filesystem, windows > > When using the filesystem provider on a localized Windows system putBlob > consistenly throws a RuntimeException. The put operation does succeed, > however, meaning a viable workaround is to catch-and-ignore. > The cause of the Exception is a UserPrincipalNotFoundException which is > thrown in org.jclouds.filesystem.util.Utils while trying to resolve the > Windows 'Everyone' user group using > UserPrincipalLookupService.lookupPrincipalByName. > Turns out the 'Everyone' group/user is only actually available on Windows > systems set to an English locale, whilst other locales will likely have > localized names for the group (tested on Norwegian Windows in which the > Everyone group is known as "Alle"). > The only ubiquitous reference to any of the built-in groups or users on a > Windows system are the SIDs. For example, 'Everyone' is known as 'S-1-1-0'. > Unfortunately, the API exposed in java.nio.file doesn't accept SIDs for > lookup, meaning there is, as far as I can tell, no pure Java solution to > resolving the UserPrincipal without knowing the (localized) name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1037) Cannot get a cloud-compute machine tag
[ https://issues.apache.org/jira/browse/JCLOUDS-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-1037. --- Resolution: Not A Problem > Cannot get a cloud-compute machine tag > -- > > Key: JCLOUDS-1037 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1037 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 1.9.1 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > > https://jclouds.apache.org/reference/javadoc/1.8.x/org/jclouds/compute/domain/ComputeMetadata.html#getTags() > fails to return tags for a rackspace cloud-compute machine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1037) Cannot get a cloud-compute machine tag
[ https://issues.apache.org/jira/browse/JCLOUDS-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015637#comment-15015637 ] Zack Shoylev commented on JCLOUDS-1037: --- The tags seen in the rackspace control panel are not available through the API. As such, it is not possible to modify them or even see them from jclouds. The tags supported in jclouds are supported through the nova metadata feature. They are a list of comma-separated strings in the metadata key-value-pairs under the key "jclouds_tags". The metadata, however, is not available from the control panel. > Cannot get a cloud-compute machine tag > -- > > Key: JCLOUDS-1037 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1037 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 1.9.1 >Reporter: Zack Shoylev >Assignee: Zack Shoylev >Priority: Minor > > https://jclouds.apache.org/reference/javadoc/1.8.x/org/jclouds/compute/domain/ComputeMetadata.html#getTags() > fails to return tags for a rackspace cloud-compute machine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCLOUDS-1037) Cannot get a cloud-compute machine tag
Zack Shoylev created JCLOUDS-1037: - Summary: Cannot get a cloud-compute machine tag Key: JCLOUDS-1037 URL: https://issues.apache.org/jira/browse/JCLOUDS-1037 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.9.1 Reporter: Zack Shoylev Assignee: Zack Shoylev Priority: Minor https://jclouds.apache.org/reference/javadoc/1.8.x/org/jclouds/compute/domain/ComputeMetadata.html#getTags() fails to return tags for a rackspace cloud-compute machine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1015) BlobStore.putBlob throws RuntimeException with filesystem provider on localized Windows
[ https://issues.apache.org/jira/browse/JCLOUDS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14959531#comment-14959531 ] Zack Shoylev commented on JCLOUDS-1015: --- I will try to have a look, maybe there is an alternative way to do this. > BlobStore.putBlob throws RuntimeException with filesystem provider on > localized Windows > --- > > Key: JCLOUDS-1015 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1015 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.1 > Environment: Microsoft Windows (tested on 7 and 10), Java 7 and 8. >Reporter: Halvdan Hoem Grelland >Assignee: Zack Shoylev >Priority: Minor > Labels: blobstore, exception, filesystem, windows > > When using the filesystem provider on a localized Windows system putBlob > consistenly throws a RuntimeException. The put operation does succeed, > however, meaning a viable workaround is to catch-and-ignore. > The cause of the Exception is a UserPrincipalNotFoundException which is > thrown in org.jclouds.filesystem.util.Utils while trying to resolve the > Windows 'Everyone' user group using > UserPrincipalLookupService.lookupPrincipalByName. > Turns out the 'Everyone' group/user is only actually available on Windows > systems set to an English locale, whilst other locales will likely have > localized names for the group (tested on Norwegian Windows in which the > Everyone group is known as "Alle"). > The only ubiquitous reference to any of the built-in groups or users on a > Windows system are the SIDs. For example, 'Everyone' is known as 'S-1-1-0'. > Unfortunately, the API exposed in java.nio.file doesn't accept SIDs for > lookup, meaning there is, as far as I can tell, no pure Java solution to > resolving the UserPrincipal without knowing the (localized) name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-1015) BlobStore.putBlob throws RuntimeException with filesystem provider on localized Windows
[ https://issues.apache.org/jira/browse/JCLOUDS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev reassigned JCLOUDS-1015: - Assignee: Zack Shoylev > BlobStore.putBlob throws RuntimeException with filesystem provider on > localized Windows > --- > > Key: JCLOUDS-1015 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1015 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.1 > Environment: Microsoft Windows (tested on 7 and 10), Java 7 and 8. >Reporter: Halvdan Hoem Grelland >Assignee: Zack Shoylev >Priority: Minor > Labels: blobstore, exception, filesystem, windows > > When using the filesystem provider on a localized Windows system putBlob > consistenly throws a RuntimeException. The put operation does succeed, > however, meaning a viable workaround is to catch-and-ignore. > The cause of the Exception is a UserPrincipalNotFoundException which is > thrown in org.jclouds.filesystem.util.Utils while trying to resolve the > Windows 'Everyone' user group using > UserPrincipalLookupService.lookupPrincipalByName. > Turns out the 'Everyone' group/user is only actually available on Windows > systems set to an English locale, whilst other locales will likely have > localized names for the group (tested on Norwegian Windows in which the > Everyone group is known as "Alle"). > The only ubiquitous reference to any of the built-in groups or users on a > Windows system are the SIDs. For example, 'Everyone' is known as 'S-1-1-0'. > Unfortunately, the API exposed in java.nio.file doesn't accept SIDs for > lookup, meaning there is, as far as I can tell, no pure Java solution to > resolving the UserPrincipal without knowing the (localized) name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
[
https://issues.apache.org/jira/browse/JCLOUDS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14953758#comment-14953758
]
Zack Shoylev commented on JCLOUDS-1013:
---
https://review.openstack.org/gitweb?p=openstack%2Fnova.git;a=commitdiff;h=b977c6626b42fbc5586f3a5326ca1a3cc0dac565
> Cannot find FloatingIPAPI nova extension against devstack
> -
>
> Key: JCLOUDS-1013
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Zack Shoylev
>Assignee: Zack Shoylev
> Fix For: 1.9.2
>
>
> Using devstack
> Nova API not returning FloatingIPApi even though the ExtensionApi was listing
> "os-floating-ips".
> Upon inspection, it is found out that the namespace for this extension is
> changed to a fake xml.
> Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
> namespace=http://docs.openstack.org/compute/ext/fake_xml,
> alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
> description=Floating IPs support.}
> (notice fake_xml in the namespace URI)
> However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
> listing it with the previous namespace:
> //Floating IPs support
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> Similar issue:
> http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
> https://github.com/jclouds/jclouds/pull/813
> Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py
> :
> # V2.1 does not support XML but we need to keep an entry in the # /extensions
> information returned to the user for backwards # compatibility FAKE_XML_URL =
> "http://docs.openstack.org/compute/ext/fake_xml;
> After changing the extension namespace in ExtensionNamespaces.java, I was
> able to make it work.
>//Floating IPs support
>//public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/compute/ext/fake_xml;;
> All extensions are returning the fake xml namespace.
> So, all of them would fail lookup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-786) Remove old swift api
[ https://issues.apache.org/jira/browse/JCLOUDS-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950513#comment-14950513 ] Zack Shoylev commented on JCLOUDS-786: -- Is that something that can be set in the softlayer provider? > Remove old swift api > > > Key: JCLOUDS-786 > URL: https://issues.apache.org/jira/browse/JCLOUDS-786 > Project: jclouds > Issue Type: Task > Components: jclouds-blobstore >Reporter: Adrian Cole > Labels: swift > Fix For: 2.0.0 > > > Particularly after JCLOUDS-523, users can switch off the rusting "swift" api > to the new "openstack-swift" api using jclouds 1.8.2 and 1.9.0. > This task tracks deletion of the old apis/swift and common/openstack modules > that are no longer necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
[
https://issues.apache.org/jira/browse/JCLOUDS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev updated JCLOUDS-1013:
--
Description:
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
/**Floating IPs support*/
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
/** * Floating IPs support *///public static final String
FLOATING_IPS = "http://docs.openstack.org/ext/floating_ips/api/v1.1;;public
static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
was:
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
```
/**Floating IPs support*/
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
```
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
/** * Floating IPs support *///public static final String
FLOATING_IPS = "http://docs.openstack.org/ext/floating_ips/api/v1.1;;public
static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
> Cannot find FloatingIPAPI nova extension against devstack
> -
>
> Key: JCLOUDS-1013
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Zack Shoylev
>Assignee: Zack Shoylev
> Fix For: 1.9.2
>
>
> Using devstack
> Nova API not returning FloatingIPApi even though the ExtensionApi was listing
> "os-floating-ips".
> Upon inspection, it is found out that the namespace for this extension is
> changed to a fake xml.
> Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
> namespace=http://docs.openstack.org/compute/ext/fake_xml,
> alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
> description=Floating IPs support.}
> (notice fake_xml in the namespace URI)
> However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
> listing it with the previous namespace:
> /**Floating IPs support*/
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> Similar issue:
> http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
> https://github.com/jclouds/jclouds/pull/813
> Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py
> :
> # V2.1 does not support XML but we need to keep an entry in the # /extensions
> information returned to the user for
[jira] [Updated] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
[
https://issues.apache.org/jira/browse/JCLOUDS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev updated JCLOUDS-1013:
--
Description:
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
```
/**Floating IPs support*/
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
```
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
/** * Floating IPs support *///public static final String
FLOATING_IPS = "http://docs.openstack.org/ext/floating_ips/api/v1.1;;public
static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
was:
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
/**Floating IPs support*/
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
/** * Floating IPs support *///public static final String
FLOATING_IPS = "http://docs.openstack.org/ext/floating_ips/api/v1.1;;public
static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
> Cannot find FloatingIPAPI nova extension against devstack
> -
>
> Key: JCLOUDS-1013
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Zack Shoylev
>Assignee: Zack Shoylev
> Fix For: 1.9.2
>
>
> Using devstack
> Nova API not returning FloatingIPApi even though the ExtensionApi was listing
> "os-floating-ips".
> Upon inspection, it is found out that the namespace for this extension is
> changed to a fake xml.
> Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
> namespace=http://docs.openstack.org/compute/ext/fake_xml,
> alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
> description=Floating IPs support.}
> (notice fake_xml in the namespace URI)
> However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
> listing it with the previous namespace:
> ```
> /**Floating IPs support*/
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> ```
> Similar issue:
> http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
> https://github.com/jclouds/jclouds/pull/813
> Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py
> :
> # V2.1 does not support XML but we need to keep an entry in the # /extensions
> information returned to the user for backwards #
[jira] [Updated] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
[
https://issues.apache.org/jira/browse/JCLOUDS-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev updated JCLOUDS-1013:
--
Description:
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
//Floating IPs support
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
//Floating IPs support
//public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
public static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
was:
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
/**Floating IPs support*/
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
/** * Floating IPs support *///public static final String
FLOATING_IPS = "http://docs.openstack.org/ext/floating_ips/api/v1.1;;public
static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
> Cannot find FloatingIPAPI nova extension against devstack
> -
>
> Key: JCLOUDS-1013
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Zack Shoylev
>Assignee: Zack Shoylev
> Fix For: 1.9.2
>
>
> Using devstack
> Nova API not returning FloatingIPApi even though the ExtensionApi was listing
> "os-floating-ips".
> Upon inspection, it is found out that the namespace for this extension is
> changed to a fake xml.
> Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
> namespace=http://docs.openstack.org/compute/ext/fake_xml,
> alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
> description=Floating IPs support.}
> (notice fake_xml in the namespace URI)
> However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
> listing it with the previous namespace:
> //Floating IPs support
> public static final String FLOATING_IPS =
> "http://docs.openstack.org/ext/floating_ips/api/v1.1;;
> Similar issue:
> http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
> https://github.com/jclouds/jclouds/pull/813
> Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py
> :
> # V2.1 does not support XML but we need to keep an entry in the # /extensions
> information returned to the user for backwards #
[jira] [Created] (JCLOUDS-1013) Cannot find FloatingIPAPI nova extension against devstack
Zack Shoylev created JCLOUDS-1013:
-
Summary: Cannot find FloatingIPAPI nova extension against devstack
Key: JCLOUDS-1013
URL: https://issues.apache.org/jira/browse/JCLOUDS-1013
Project: jclouds
Issue Type: Bug
Affects Versions: 1.9.1, 2.0.0
Reporter: Zack Shoylev
Assignee: Zack Shoylev
Fix For: 1.9.2
Using devstack
Nova API not returning FloatingIPApi even though the ExtensionApi was listing
"os-floating-ips".
Upon inspection, it is found out that the namespace for this extension is
changed to a fake xml.
Ex: Extension{id=os-floating-ips, name=FloatingIps, links=[],
namespace=http://docs.openstack.org/compute/ext/fake_xml,
alias=os-floating-ips, updated=Tue Dec 02 16:00:00 PST 2014,
description=Floating IPs support.}
(notice fake_xml in the namespace URI)
However, org.jclouds.openstack.nova.v2_0.extensions.ExtensionNamespaces is
listing it with the previous namespace:
/**Floating IPs support*/
public static final String FLOATING_IPS =
"http://docs.openstack.org/ext/floating_ips/api/v1.1;;
Similar issue:
http://stackoverflow.com/questions/31417247/jcloud-nova-unable-to-find-floating-ip-pool-extension
https://github.com/jclouds/jclouds/pull/813
Relevant comment from /opt/stack/nova/api/openstack/compute/extension_info.py :
# V2.1 does not support XML but we need to keep an entry in the # /extensions
information returned to the user for backwards # compatibility FAKE_XML_URL =
"http://docs.openstack.org/compute/ext/fake_xml;
After changing the extension namespace in ExtensionNamespaces.java, I was able
to make it work.
/** * Floating IPs support *///public static final String
FLOATING_IPS = "http://docs.openstack.org/ext/floating_ips/api/v1.1;;public
static final String FLOATING_IPS =
"http://docs.openstack.org/compute/ext/fake_xml;;
All extensions are returning the fake xml namespace.
So, all of them would fail lookup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1003) IpProtocol.ANY does not work on OpenStack
[
https://issues.apache.org/jira/browse/JCLOUDS-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900851#comment-14900851
]
Zack Shoylev commented on JCLOUDS-1003:
---
http://docs.openstack.org/openstack-ops/content/security_groups.html
https://github.com/apache/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/domain/Ingress.java#L24
> IpProtocol.ANY does not work on OpenStack
> -
>
> Key: JCLOUDS-1003
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1003
> Project: jclouds
> Issue Type: Bug
> Environment: OpenStack Nova on BlueBox Cloud
>Reporter: Andrew Kennedy
>
> Trying to add IpPermissions.permitAnyProtocol() or any IpPermission using
> IpProtocol.ANY fails with the following error:
> 2015-09-21 07:03:57,972 DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService
> [brooklyn-execmanager-L0pLKIH7-132]: Sending request 193768812: POST
> https://cloudsoft-sjc.openstack.blueboxgrid.com:8777/v2/bba97b44a7dd40b1ad8a0b90510129f7/os-security-group-rules
> HTTP/1.1
> 2015-09-21 07:03:57,972 DEBUG jclouds.wire
> [brooklyn-execmanager-L0pLKIH7-132]: >>
> "{"security_group_rule":{"parent_group_id":"1d958f15-aeef-4ee8-a527-71f7fcae9864","cidr":"0.0.0.0/0","ip_protocol":"-1","from_port":"1","to_port":"65535"}}"
> 2015-09-21 07:03:58,793 DEBUG jclouds.wire
> [brooklyn-execmanager-L0pLKIH7-132]: << "{"badRequest": {"message": "Invalid
> IP protocol -1.", "code": 400}}"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1003) IpProtocol.ANY does not work on OpenStack
[
https://issues.apache.org/jira/browse/JCLOUDS-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900878#comment-14900878
]
Zack Shoylev commented on JCLOUDS-1003:
---
I am guessing the protocol needs to be updated with a new enum that uses the
openstack protocol description.
> IpProtocol.ANY does not work on OpenStack
> -
>
> Key: JCLOUDS-1003
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1003
> Project: jclouds
> Issue Type: Bug
> Environment: OpenStack Nova on BlueBox Cloud
>Reporter: Andrew Kennedy
>
> Trying to add IpPermissions.permitAnyProtocol() or any IpPermission using
> IpProtocol.ANY fails with the following error:
> 2015-09-21 07:03:57,972 DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService
> [brooklyn-execmanager-L0pLKIH7-132]: Sending request 193768812: POST
> https://cloudsoft-sjc.openstack.blueboxgrid.com:8777/v2/bba97b44a7dd40b1ad8a0b90510129f7/os-security-group-rules
> HTTP/1.1
> 2015-09-21 07:03:57,972 DEBUG jclouds.wire
> [brooklyn-execmanager-L0pLKIH7-132]: >>
> "{"security_group_rule":{"parent_group_id":"1d958f15-aeef-4ee8-a527-71f7fcae9864","cidr":"0.0.0.0/0","ip_protocol":"-1","from_port":"1","to_port":"65535"}}"
> 2015-09-21 07:03:58,793 DEBUG jclouds.wire
> [brooklyn-execmanager-L0pLKIH7-132]: << "{"badRequest": {"message": "Invalid
> IP protocol -1.", "code": 400}}"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-1000) Suport Rackspace Cloud Images
[ https://issues.apache.org/jira/browse/JCLOUDS-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev reassigned JCLOUDS-1000: - Assignee: Zack Shoylev > Suport Rackspace Cloud Images > - > > Key: JCLOUDS-1000 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1000 > Project: jclouds > Issue Type: New Feature >Reporter: Gary Marchiny >Assignee: Zack Shoylev > > In order to import an image to Rackspace, the following two steps must be > taken: > 1. Upload your image data to your Cloud Files account > 2. Create a Cloud Images import task > The first step is currently possible using jClouds. The second step is not. > A jClouds service / API to support Rackspace Cloud Images would make this > possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1000) Suport Rackspace Cloud Images
[ https://issues.apache.org/jira/browse/JCLOUDS-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14745934#comment-14745934 ] Zack Shoylev commented on JCLOUDS-1000: --- I will have a look. > Suport Rackspace Cloud Images > - > > Key: JCLOUDS-1000 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1000 > Project: jclouds > Issue Type: New Feature >Reporter: Gary Marchiny >Assignee: Zack Shoylev > > In order to import an image to Rackspace, the following two steps must be > taken: > 1. Upload your image data to your Cloud Files account > 2. Create a Cloud Images import task > The first step is currently possible using jClouds. The second step is not. > A jClouds service / API to support Rackspace Cloud Images would make this > possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1000) Suport Rackspace Cloud Images
[ https://issues.apache.org/jira/browse/JCLOUDS-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14745951#comment-14745951 ] Zack Shoylev commented on JCLOUDS-1000: --- This is the API call referenced: http://docs.rackspace.com/images/api/v2/ci-devguide/content/POST_importImage_tasks_Image_Task_Calls.html The openstack version of the call is here: http://developer.openstack.org/api-ref-image-v2.html These are the glance-supported operations we currently have in jclouds: https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-glance/src/main/java/org/jclouds/openstack/glance/v1_0/features/ImageApi.java Notice that only v1 is supported for the openstack-labs glance code, whereas Rackspace uses glance v2. > Suport Rackspace Cloud Images > - > > Key: JCLOUDS-1000 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1000 > Project: jclouds > Issue Type: New Feature >Reporter: Gary Marchiny >Assignee: Zack Shoylev > > In order to import an image to Rackspace, the following two steps must be > taken: > 1. Upload your image data to your Cloud Files account > 2. Create a Cloud Images import task > The first step is currently possible using jClouds. The second step is not. > A jClouds service / API to support Rackspace Cloud Images would make this > possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-999) Unable to Authenticate with Rackspace Glance
[
https://issues.apache.org/jira/browse/JCLOUDS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14740870#comment-14740870
]
Zack Shoylev commented on JCLOUDS-999:
--
It uses the API directly. So this explains why you would not be able to access
it.
> Unable to Authenticate with Rackspace Glance
>
>
> Key: JCLOUDS-999
> URL: https://issues.apache.org/jira/browse/JCLOUDS-999
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1
> Environment: Eclipse IDE on Mac OSx
>Reporter: Gary Marchiny
>Assignee: Zack Shoylev
>
> Using jClouds version 1.9.1 with Rackspace OpenStack on Mac OSx 10.10.3 in
> Eclipse IDE.
> When attempting to make any API calls with glance, I get a 401 Unauthorized
> response. With the same credentials, all other API calls seem to work (e.g.
> via nova API).
> Here is my Java code:
> ImageApi imageApi = ContextBuilder.newBuilder("openstack-glance")
> .endpoint("https://identity.api.rackspacecloud.com/v2.0/;)
> .credentials(clientConfiguration.getUserName(),
> clientConfiguration.getApiKey())
> .buildApi(GlanceApi.class).getImageApi("IAD");
> imageApi.list();
> Here is the response from the above API call:
> Stack trace: org.jclouds.rest.AuthorizationException: POST
> https://identity.api.rackspacecloud.com/v2.0/tokens HTTP/1.1 -> HTTP/1.1 401
> Unauthorized
> at
> org.jclouds.openstack.glance.v1_0.handlers.GlanceErrorHandler.handleError(GlanceErrorHandler.java:57)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:136)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:105)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at
> com.sun.proxy.$Proxy67.authenticateWithTenantNameAndCredentials(Unknown
> Source)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:43)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:31)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:81)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:36)
> at
> com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:148)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3524)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2317)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2280)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2195)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3934)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4827)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:234)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:231)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:94)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:54)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:73)
> at
>
[jira] [Assigned] (JCLOUDS-999) Unable to Authenticate with Rackspace Glance
[
https://issues.apache.org/jira/browse/JCLOUDS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev reassigned JCLOUDS-999:
Assignee: Zack Shoylev
> Unable to Authenticate with Rackspace Glance
>
>
> Key: JCLOUDS-999
> URL: https://issues.apache.org/jira/browse/JCLOUDS-999
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1
> Environment: Eclipse IDE on Mac OSx
>Reporter: Gary Marchiny
>Assignee: Zack Shoylev
>
> Using jClouds version 1.9.1 with Rackspace OpenStack on Mac OSx 10.10.3 in
> Eclipse IDE.
> When attempting to make any API calls with glance, I get a 401 Unauthorized
> response. With the same credentials, all other API calls seem to work (e.g.
> via nova API).
> Here is my Java code:
> ImageApi imageApi = ContextBuilder.newBuilder("openstack-glance")
> .endpoint("https://identity.api.rackspacecloud.com/v2.0/;)
> .credentials(clientConfiguration.getUserName(),
> clientConfiguration.getApiKey())
> .buildApi(GlanceApi.class).getImageApi("IAD");
> imageApi.list();
> Here is the response from the above API call:
> Stack trace: org.jclouds.rest.AuthorizationException: POST
> https://identity.api.rackspacecloud.com/v2.0/tokens HTTP/1.1 -> HTTP/1.1 401
> Unauthorized
> at
> org.jclouds.openstack.glance.v1_0.handlers.GlanceErrorHandler.handleError(GlanceErrorHandler.java:57)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:136)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:105)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at
> com.sun.proxy.$Proxy67.authenticateWithTenantNameAndCredentials(Unknown
> Source)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:43)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:31)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:81)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:36)
> at
> com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:148)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3524)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2317)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2280)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2195)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3934)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4827)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:234)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:231)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:94)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:54)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:73)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
>
[jira] [Commented] (JCLOUDS-999) Unable to Authenticate with Rackspace Glance
[
https://issues.apache.org/jira/browse/JCLOUDS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14740835#comment-14740835
]
Zack Shoylev commented on JCLOUDS-999:
--
I will try to reproduce this issue later today. Any additional info would be
appreciated, such as if it's also reproducible with older versions.
> Unable to Authenticate with Rackspace Glance
>
>
> Key: JCLOUDS-999
> URL: https://issues.apache.org/jira/browse/JCLOUDS-999
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1
> Environment: Eclipse IDE on Mac OSx
>Reporter: Gary Marchiny
>Assignee: Zack Shoylev
>
> Using jClouds version 1.9.1 with Rackspace OpenStack on Mac OSx 10.10.3 in
> Eclipse IDE.
> When attempting to make any API calls with glance, I get a 401 Unauthorized
> response. With the same credentials, all other API calls seem to work (e.g.
> via nova API).
> Here is my Java code:
> ImageApi imageApi = ContextBuilder.newBuilder("openstack-glance")
> .endpoint("https://identity.api.rackspacecloud.com/v2.0/;)
> .credentials(clientConfiguration.getUserName(),
> clientConfiguration.getApiKey())
> .buildApi(GlanceApi.class).getImageApi("IAD");
> imageApi.list();
> Here is the response from the above API call:
> Stack trace: org.jclouds.rest.AuthorizationException: POST
> https://identity.api.rackspacecloud.com/v2.0/tokens HTTP/1.1 -> HTTP/1.1 401
> Unauthorized
> at
> org.jclouds.openstack.glance.v1_0.handlers.GlanceErrorHandler.handleError(GlanceErrorHandler.java:57)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:136)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:105)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at
> com.sun.proxy.$Proxy67.authenticateWithTenantNameAndCredentials(Unknown
> Source)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:43)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:31)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:81)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:36)
> at
> com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:148)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3524)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2317)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2280)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2195)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3934)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4827)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:234)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:231)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:94)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:54)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:73)
> at
>
[jira] [Closed] (JCLOUDS-999) Unable to Authenticate with Rackspace Glance
[
https://issues.apache.org/jira/browse/JCLOUDS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev closed JCLOUDS-999.
Resolution: Not A Problem
> Unable to Authenticate with Rackspace Glance
>
>
> Key: JCLOUDS-999
> URL: https://issues.apache.org/jira/browse/JCLOUDS-999
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 1.9.1
> Environment: Eclipse IDE on Mac OSx
>Reporter: Gary Marchiny
>Assignee: Zack Shoylev
>
> Using jClouds version 1.9.1 with Rackspace OpenStack on Mac OSx 10.10.3 in
> Eclipse IDE.
> When attempting to make any API calls with glance, I get a 401 Unauthorized
> response. With the same credentials, all other API calls seem to work (e.g.
> via nova API).
> Here is my Java code:
> ImageApi imageApi = ContextBuilder.newBuilder("openstack-glance")
> .endpoint("https://identity.api.rackspacecloud.com/v2.0/;)
> .credentials(clientConfiguration.getUserName(),
> clientConfiguration.getApiKey())
> .buildApi(GlanceApi.class).getImageApi("IAD");
> imageApi.list();
> Here is the response from the above API call:
> Stack trace: org.jclouds.rest.AuthorizationException: POST
> https://identity.api.rackspacecloud.com/v2.0/tokens HTTP/1.1 -> HTTP/1.1 401
> Unauthorized
> at
> org.jclouds.openstack.glance.v1_0.handlers.GlanceErrorHandler.handleError(GlanceErrorHandler.java:57)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:136)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:105)
> 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.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at
> com.sun.proxy.$Proxy67.authenticateWithTenantNameAndCredentials(Unknown
> Source)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:43)
> at
> org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:31)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:81)
> at
> org.jclouds.openstack.keystone.v2_0.functions.internal.BaseAuthenticator.apply(BaseAuthenticator.java:36)
> at
> com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:148)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3524)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2317)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2280)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2195)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3934)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4827)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:234)
> at
> org.jclouds.openstack.keystone.v2_0.config.KeystoneAuthenticationModule$2.get(KeystoneAuthenticationModule.java:231)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:94)
> at
> org.jclouds.openstack.keystone.v2_0.suppliers.LocationIdToURIFromAccessForTypeAndVersion.get(LocationIdToURIFromAccessForTypeAndVersion.java:54)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:73)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
>
[jira] [Created] (JCLOUDS-986) java 1.8 + glassfish 4 + jclouds 1.9.1 results in an exception
Zack Shoylev created JCLOUDS-986: Summary: java 1.8 + glassfish 4 + jclouds 1.9.1 results in an exception Key: JCLOUDS-986 URL: https://issues.apache.org/jira/browse/JCLOUDS-986 Project: jclouds Issue Type: Bug Reporter: Zack Shoylev Assignee: Zack Shoylev com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: com.google.common.util.concurrent.ExecutionError: java.lang.NoSuchMethodError: com.google.common.reflect.TypeToken.method(Ljava/lang/reflect/Method;)Lcom/google/common/reflect/Invokable; com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: com.google.common.util.concurrent.ExecutionError: java.lang.NoSuchMethodError: com.google.common.reflect.TypeToken.method(Ljava/lang/reflect/Method;)Lcom/google/common/reflect/Invokable; at com.google.inject.internal.util.$MapMaker$StrategyImpl.compute(MapMaker.java:553) at com.google.inject.internal.util.$MapMaker$StrategyImpl.compute(MapMaker.java:419) at com.google.inject.internal.util.$CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2041) at com.google.inject.internal.FailableCache.get(FailableCache.java:50) at com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:49) at com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:125) at com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:521) at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:847) at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:772) at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:256) at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:205) at com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:853) at com.google.inject.internal.BoundProviderFactory.notify(BoundProviderFactory.java:44) at com.google.inject.internal.ProcessedBindingData.runCreationListeners(ProcessedBindingData.java:50) at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:133) at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106) at com.google.inject.Guice.createInjector(Guice.java:95) at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:402) at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:326) at org.jclouds.ContextBuilder.buildApi(ContextBuilder.java:644) at org.jclouds.ContextBuilder.buildApi(ContextBuilder.java:636) at com….. from my code at com…… from my code at org.apache.commons.pool2.BasePooledObjectFactory.makeObject(BasePooledObjectFactory.java:57) at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:819) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:429) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:360) at com….. from my code at com…… from my code at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:408) at org.apache.camel.component.bean.MethodInfo$1.doProceed(MethodInfo.java:279) at org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:252) at org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:167) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:416) at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) at org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:111) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:416) at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[jira] [Commented] (JCLOUDS-802) Non-metadata Swift headers cannot be updated
[ https://issues.apache.org/jira/browse/JCLOUDS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662379#comment-14662379 ] Zack Shoylev commented on JCLOUDS-802: -- https://github.com/jclouds/jclouds/blame/master/apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/features/ContainerApi.java#L178 This is not fixed yet. We will have to add updateHeaders (similar to ObjectApi) to ContainerApi, if I understand the issue correctly. Non-metadata Swift headers cannot be updated Key: JCLOUDS-802 URL: https://issues.apache.org/jira/browse/JCLOUDS-802 Project: jclouds Issue Type: Bug Components: jclouds-blobstore Affects Versions: 1.8.1 Reporter: Jeremy Daggett Assignee: Jeremy Daggett Labels: openstack-swift Swift has the ability to update additional headers (metadata) associated with either a [container|http://docs.rackspace.com/files/api/v1/cf-devguide/content/POST_updateacontainermeta_v1__account___container__containerServicesOperations_d1e000.html] or an [object|http://docs.rackspace.com/files/api/v1/cf-devguide/content/POST_updateaobjmeta_v1__account___container___object__objectServicesOperations_d1e000.html]. The ContainerApi and ObjectApi updateMetadata() method should allow updates to these additional headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-791) Promote rackspace-cloudfiles
[ https://issues.apache.org/jira/browse/JCLOUDS-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-791. -- Resolution: Fixed Fix Version/s: 1.9.1 Promote rackspace-cloudfiles Key: JCLOUDS-791 URL: https://issues.apache.org/jira/browse/JCLOUDS-791 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Reporter: Everett Toews Assignee: Zack Shoylev Labels: openstack-swift, rackspace Fix For: 2.0.0, 1.9.1 Promote the rackspace-cloudfiles providers in jclouds/jclouds-labs-openstack to jclouds/jclouds as per [Promote a Provider|https://cwiki.apache.org/confluence/display/JCLOUDS/Promote+a+Provider] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-883) Swift portable copy blob cannot replace user metadata
[
https://issues.apache.org/jira/browse/JCLOUDS-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660706#comment-14660706
]
Zack Shoylev commented on JCLOUDS-883:
--
[~khc] I think this might be fixed in 1.9.1; can you look into
https://github.com/jclouds/jclouds/blob/master/apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/features/ObjectApi.java
You will see we have both updateMetadata and updateHeaders, which should fix
this issue, I think.
Swift portable copy blob cannot replace user metadata
-
Key: JCLOUDS-883
URL: https://issues.apache.org/jira/browse/JCLOUDS-883
Project: jclouds
Issue Type: Bug
Components: jclouds-blobstore
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Priority: Minor
Labels: openstack-swift
Fix For: 2.0.0
Swift only allows appending to user metadata, different from other object
stores, such that the following integration test fails:
{noformat}
Failed tests:
CloudFilesUSBlobIntegrationLiveTestBaseBlobIntegrationTest.testCopyBlobReplaceMetadata:812-BaseBlobIntegrationTest.checkUserMetadata:606
Expecting:
{key2=value2, key3=value3, key1=value1, key4=value4}
to be equal to:
{key3=value3, key4=value4}
but was not.
{noformat}
Unfortunately the provider API does not appear to provide a way to set the
combination of content and user metadata to fix this up after the fact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-851) Contribution for Nova os-hypervisors Extension.
[ https://issues.apache.org/jira/browse/JCLOUDS-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651803#comment-14651803 ] Zack Shoylev commented on JCLOUDS-851: -- https://github.com/jclouds/jclouds/commit/d7c4867752809d96dba26eee10438d52a8f9bd53 Contribution for Nova os-hypervisors Extension. - Key: JCLOUDS-851 URL: https://issues.apache.org/jira/browse/JCLOUDS-851 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.8.1 Reporter: Alka Beniwal Labels: openstack-nova Fix For: 2.0.0, 1.9.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-851) Contribution for Nova os-hypervisors Extension.
[ https://issues.apache.org/jira/browse/JCLOUDS-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev resolved JCLOUDS-851. -- Resolution: Fixed Contribution for Nova os-hypervisors Extension. - Key: JCLOUDS-851 URL: https://issues.apache.org/jira/browse/JCLOUDS-851 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.8.1 Reporter: Alka Beniwal Labels: openstack-nova Fix For: 2.0.0, 1.9.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-979) BaseJdbcBlobStoreTest.testRanges failure
[
https://issues.apache.org/jira/browse/JCLOUDS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651800#comment-14651800
]
Zack Shoylev commented on JCLOUDS-979:
--
From looking at this, it seems like LocalBlobStore should be fixed?
BaseJdbcBlobStoreTest.testRanges failure
Key: JCLOUDS-979
URL: https://issues.apache.org/jira/browse/JCLOUDS-979
Project: jclouds
Issue Type: Bug
Components: jclouds-blobstore, jclouds-labs
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Roman Coedo
Priority: Minor
{noformat}
java.lang.ClassCastException: org.jclouds.jdbc.util.JdbcInputStream cannot be
cast to com.google.common.io.ByteSource
at
org.jclouds.blobstore.config.LocalBlobStore.getBlob(LocalBlobStore.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
at com.sun.proxy.$Proxy58.getBlob(Unknown Source)
at
org.jclouds.jdbc.BaseJdbcBlobStoreTest.testRanges(BaseJdbcBlobStoreTest.java:596)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
From:
https://jclouds.ci.cloudbees.com/job/jclouds-labs/1061/org.apache.jclouds.labs$jdbc/testReport/junit/org.jclouds.jdbc/EclipselinkH2BlobStoreTest/testRanges/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCLOUDS-980) Add support for nova group affinity
Zack Shoylev created JCLOUDS-980: Summary: Add support for nova group affinity Key: JCLOUDS-980 URL: https://issues.apache.org/jira/browse/JCLOUDS-980 Project: jclouds Issue Type: Improvement Components: jclouds-compute Affects Versions: 2.0.0 Reporter: Zack Shoylev Add support for nova affinity groups https://wiki.openstack.org/wiki/InstanceGroupApiExtension Also see server-group-create Create a new server group with the specified server-group-delete Delete specific server group(s). server-group-getGet a specific server group. server-group-list Print a list of all server groups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-980) Add support for nova group affinity
[ https://issues.apache.org/jira/browse/JCLOUDS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zack Shoylev reassigned JCLOUDS-980: Assignee: Zack Shoylev Add support for nova group affinity --- Key: JCLOUDS-980 URL: https://issues.apache.org/jira/browse/JCLOUDS-980 Project: jclouds Issue Type: Improvement Components: jclouds-compute Affects Versions: 2.0.0 Reporter: Zack Shoylev Assignee: Zack Shoylev Add support for nova affinity groups https://wiki.openstack.org/wiki/InstanceGroupApiExtension Also see server-group-create Create a new server group with the specified server-group-delete Delete specific server group(s). server-group-getGet a specific server group. server-group-list Print a list of all server groups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14646151#comment-14646151
]
Zack Shoylev commented on JCLOUDS-975:
--
https://github.com/jclouds/jclouds/pull/831
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Fix For: 1.9.1
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14646114#comment-14646114
]
Zack Shoylev commented on JCLOUDS-975:
--
Ok. There are additional failures outside of Nova. I will look into it!
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Fix For: 1.9.1
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644430#comment-14644430
]
Zack Shoylev commented on JCLOUDS-975:
--
Yep, broken, but haven't been able to figure it out yet.
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644480#comment-14644480
]
Zack Shoylev commented on JCLOUDS-975:
--
https://github.com/jclouds/jclouds/pull/829
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644469#comment-14644469
]
Zack Shoylev commented on JCLOUDS-975:
--
You can add this dependency to figure out where the problem is:
dependency
groupIdcom.google.code.findbugs/groupId
artifactIdjsr305/artifactId
version1.3.9/version
/dependency
This will alert you that one of the tests is using a method call but does not
check the returned value. Adding an assert will fix that, and the dependency is
not needed.
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev resolved JCLOUDS-975.
--
Resolution: Fixed
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCLOUDS-975) compilation failures with Guava 19.0-rc1
[
https://issues.apache.org/jira/browse/JCLOUDS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zack Shoylev updated JCLOUDS-975:
-
Fix Version/s: 1.9.1
compilation failures with Guava 19.0-rc1
Key: JCLOUDS-975
URL: https://issues.apache.org/jira/browse/JCLOUDS-975
Project: jclouds
Issue Type: Improvement
Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Andrew Gaul
Assignee: Zack Shoylev
Labels: openstack-nova
Fix For: 1.9.1
Seen when running {{mvn clean test-compile -Dguava.version=19.0-rc1}}:
{noformat}
[INFO] Compiling 124 source files to
/home/gaul/work/jclouds/apis/openstack-nova/target/test-classes
warning: No processor claimed any of these annotations:
org.testng.annotations.AfterClass,org.jclouds.rest.annotations.ResponseParser,org.testng.annotations.DataProvider,org.testng.annotations.BeforeClass,org.testng.annotations.BeforeMethod,org.testng.annotations.Test,org.jclouds.rest.annotations.SelectJson,org.testng.annotations.AfterMethod,org.testng.annotations.BeforeTest,javax.ws.rs.Consumes,org.testng.annotations.BeforeGroups
error: cannot access CheckReturnValue
class file for javax.annotation.CheckReturnValue not found
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
javax.annotation.CheckReturnValue not found
{noformat}
We should investigate this before Guava 19.0 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCLOUDS-965) Ensure jclouds retries properly when writing the request is interrupted
Zack Shoylev created JCLOUDS-965: Summary: Ensure jclouds retries properly when writing the request is interrupted Key: JCLOUDS-965 URL: https://issues.apache.org/jira/browse/JCLOUDS-965 Project: jclouds Issue Type: Bug Reporter: Zack Shoylev Assignee: Zack Shoylev Fix For: 2.0.0 Ensure jclouds will properly retry an http request when the request is interrupted by the server closing the socket. http://stackoverflow.com/questions/31453750/jcloud-ioexpection-error-writing-request-body-to-server/31457544 It seems there might be an actual problem, but I am still tracking it down. There are some issues with testing specifically for this case: https://github.com/square/okhttp/issues/1755 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
