[jira] [Commented] (JCLOUDS-1366) OutOfMemory when InputStream referencing to big file is used as payload

[Zack Shoylev (JIRA)]

[ 
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)

Re: [jclouds/jclouds] JCLOUDS-1264: Use core BindToJsonPayload to send OpenStack Swift multipart manifests (#1083)

[Zack Shoylev]

Even though we use project.build.sourceEncoding, on Windows, you still seem to 
have to specify file encoding explicitly using JAVA_TOOL_OPTIONS
i.e.:
[Environment]::SetEnvironmentVariable("JAVA_TOOLS_OPTIONS", 
"-Dfile.encoding=UTF8", "Machine")

otherwise the new test fails. Leads me to think we might have to do some 
additional tweaking so this is not necessary

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1083#issuecomment-293865096

Re: [jclouds/jclouds] JCLOUDS-1263: URL encode object names from list object response before creating URIs with them (#1084)

[Zack Shoylev]

Looks good

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1084#issuecomment-291242800

[jira] [Commented] (JCLOUDS-1251) Swift removeBlob

[Zack Shoylev (JIRA)]

[ 
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)

Re: [jclouds/jclouds] Handle IOException for XATTRS when reading blob on Docker (#1066)

[Zack Shoylev]

@geertvanheusden The commits will have to be squashed, at least. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1066#issuecomment-283416924

Re: [jclouds/jclouds] Handle IOException for XATTRS when reading blob on Docker (#1066)

[Zack Shoylev]

rebuild please

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1066#issuecomment-283416637

Re: [jclouds/jclouds] Handle IOException for XATTRS when reading blob on Docker (#1066)

[Zack Shoylev]

It seems XATTR_CONTENT_MD5 should be handled as well, but I am not very sure 
what's going on with how it's used.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1066#issuecomment-283147308

[jira] [Commented] (JCLOUDS-1240) MultiPart Upload Swift

[Zack Shoylev (JIRA)]

[ 
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)

Re: [jclouds/jclouds] [JCLOUDS-1233] bump jax-rs version (#1057)

[Zack Shoylev]

> jclouds-labs-openstack seems to have building problems independent of that PR

I'll have a look

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1057#issuecomment-277374369

[jira] [Commented] (JCLOUDS-1225) Guava 21 compatibility

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

 [ 
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

[Zack Shoylev (JIRA)]

 [ 
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)

Re: [jclouds/jclouds] Allow ipv6 address blocks (#1047)

[Zack Shoylev]

Closed #1047.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1047#event-918173596

Re: [jclouds/jclouds] Allow ipv6 address blocks (#1047)

[Zack Shoylev]

merged and backported to 2.0.x

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1047#issuecomment-271697664

Re: [jclouds/jclouds] WindowsEveryonePrincipal : update regex for FR (#1049)

[Zack Shoylev]

Closed #1049.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1049#event-918104364

[jira] [Commented] (JCLOUDS-1222) UserPrincipalNotFound with a french Windows

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

 [ 
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)

Re: [jclouds/jclouds] WindowsEveryonePrincipal : update regex for FR (#1049)

[Zack Shoylev]

merged and backported to 2.0.x

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1049#issuecomment-271684603

Re: [jclouds/jclouds] Allow ipv6 address blocks (#1047)

[Zack Shoylev]

@nacx Is this what you had in mind? I am asking because the logic needed to 
avoid the regex was a little bit more complex than just splitting.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1047#issuecomment-271667868

Re: [jclouds/jclouds] Allow ipv6 address blocks (#1047)

[Zack Shoylev]

@zack-shoylev pushed 1 commit.

96a1cfe  One more test, review changes.


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/jclouds/jclouds/pull/1047/files/8f39e36da24fb69acf82d1f574789c83852d31aa..96a1cfeaedcda3249d6894edbeb2e2477af904fc

Re: [jclouds/jclouds] WindowsEveryonePrincipal : update regex for FR (#1049)

[Zack Shoylev]

Ah, very good find.

+1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1049#issuecomment-270681381

[jclouds/jclouds] Allow ipv6 address blocks (#1047)

[Zack Shoylev]

https://issues.apache.org/jira/browse/JCLOUDS-1100
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1047

-- Commit Summary --

  * Allow ipv6 address blocks

-- File Changes --

M core/src/main/java/org/jclouds/util/Strings2.java (31)
M core/src/test/java/org/jclouds/util/Strings2Test.java (3)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1047.patch
https://github.com/jclouds/jclouds/pull/1047.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1047

Re: [jclouds/jclouds] Ensures parallel tests don't step on each other in Static Large Objec… (#935)

[Zack Shoylev]

Closed #935.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/935#event-909919093

Re: [jclouds/jclouds] Change BaseSwiftApiLiveTest to inherit from BaseBlobStoreIntegrationT… (#1044)

[Zack Shoylev]

merged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1044#issuecomment-268372173

Re: [jclouds/jclouds] Change BaseSwiftApiLiveTest to inherit from BaseBlobStoreIntegrationT… (#1044)

[Zack Shoylev]

Closed #1044.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1044#event-900799910

Re: [jclouds/jclouds] Change BaseSwiftApiLiveTest to inherit from BaseBlobStoreIntegrationT… (#1044)

[Zack Shoylev]

Reopened #1044.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1044#event-900594339

Re: [jclouds/jclouds] Change BaseSwiftApiLiveTest to inherit from BaseBlobStoreIntegrationT… (#1044)

[Zack Shoylev]

Closed #1044.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1044#event-900592473

[jclouds/jclouds] Change BaseSwiftApiLiveTest to inherit from BaseBlobStoreIntegrationT… (#1044)

[Zack Shoylev]

…est and use its methods

Based on an old suggestion from https://github.com/jclouds/jclouds/pull/935
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1044

-- Commit Summary --

  * Change BaseSwiftApiLiveTest to inherit from BaseBlobStoreIntegrationTest 
and use its methods

-- File Changes --

M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/TemporaryUrlSignerLiveTest.java
 (23)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/AccountApiLiveTest.java
 (11)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/BulkApiLiveTest.java
 (21)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/ContainerApiLiveTest.java
 (43)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/CreatePublicContainerLiveTest.java
 (15)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/ObjectApiLiveTest.java
 (70)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/StaticLargeObjectApiLiveTest.java
 (31)
M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/internal/BaseSwiftApiLiveTest.java
 (38)
M 
apis/rackspace-cloudfiles/src/test/java/org/jclouds/rackspace/cloudfiles/v1/features/CloudFilesAccountApiLiveTest.java
 (2)
M 
apis/rackspace-cloudfiles/src/test/java/org/jclouds/rackspace/cloudfiles/v1/features/CloudFilesCDNApiLiveTest.java
 (38)
M 
apis/rackspace-cloudfiles/src/test/java/org/jclouds/rackspace/cloudfiles/v1/internal/BaseCloudFilesApiLiveTest.java
 (7)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1044.patch
https://github.com/jclouds/jclouds/pull/1044.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1044

Re: [jclouds/jclouds] Make user agent header configurable (#1043)

[Zack Shoylev]

> In our use case, we would like to override the complete user agent string.

Good to know! 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1043#issuecomment-268059499

Re: [jclouds/jclouds] Make user agent header configurable (#1043)

[Zack Shoylev]

zack-shoylev commented on this pull request.



>  
@Inject
public JavaUrlHttpCommandExecutorService(HttpUtils utils, 
ContentMetadataCodec contentMetadataCodec,
  DelegatingRetryHandler retryHandler, IOExceptionRetryHandler 
ioRetryHandler,
  DelegatingErrorHandler errorHandler, HttpWire wire, 
@Named("untrusted") HostnameVerifier verifier,
  @Named("untrusted") Supplier untrustedSSLContextProvider, 
Function<URI, Proxy> proxyForURI,
- @Named(PROPERTY_IDEMPOTENT_METHODS) String idempotentMethods) {
+ @Named(PROPERTY_IDEMPOTENT_METHODS) String idempotentMethods,
+@Named(PROPERTY_USER_AGENT) String userAgent) {

Seems like there is a tab here?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1043#pullrequestreview-13626695

Re: [jclouds/jclouds] Make user agent header configurable (#1043)

[Zack Shoylev]

zack-shoylev commented on this pull request.



>  
@Inject
OkHttpCommandExecutorService(HttpUtils utils, ContentMetadataCodec 
contentMetadataCodec,
  DelegatingRetryHandler retryHandler, IOExceptionRetryHandler 
ioRetryHandler,
  DelegatingErrorHandler errorHandler, HttpWire wire, Function<URI, 
Proxy> proxyForURI, OkHttpClient okHttpClient,
- @Named(PROPERTY_IDEMPOTENT_METHODS) String idempotentMethods) {
+ @Named(PROPERTY_IDEMPOTENT_METHODS) String idempotentMethods,
+@Named(PROPERTY_USER_AGENT) String userAgent) {

And here

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1043#pullrequestreview-13626782

Re: [jclouds/jclouds] Make user agent header configurable (#1043)

[Zack Shoylev]

zack-shoylev commented on this pull request.



>  
@Inject
ApacheHCHttpCommandExecutorService(HttpUtils utils, ContentMetadataCodec 
contentMetadataCodec,
  DelegatingRetryHandler retryHandler, IOExceptionRetryHandler 
ioRetryHandler,
  DelegatingErrorHandler errorHandler, HttpWire wire, HttpClient client,
- @Named(PROPERTY_IDEMPOTENT_METHODS) String idempotentMethods) {
+ @Named(PROPERTY_IDEMPOTENT_METHODS) String idempotentMethods,
+@Named(PROPERTY_USER_AGENT) String userAgent) {

And here

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1043#pullrequestreview-13626747

Re: [jclouds/jclouds] Make user agent header configurable (#1043)

[Zack Shoylev]

Whitespace seems a bit off. I also would have preferred concatenating 
additional information on the default user agent string instead of replacing 
it, I think. Thoughts? Is a completely custom user agent required for an 
application?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1043#issuecomment-268053507

[jira] [Commented] (JCLOUDS-1064) multipart upload throwing : NullPointerException: Null partETag

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

 [ 
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)

Re: [jira] [Created] (JCLOUDS-1205) Setting a custom pool name with floatingIpPoolNames() in NovaTemplateOptions seems to have no effect

[Zack Shoylev]

Can you also share the relevant part of the wire log? 
https://jclouds.apache.org/reference/logging/

It will help us figure out if and why jclouds is not sending the floating ip 
pool name.

From: Michael Militzer (JIRA) 
Sent: Friday, November 25, 2016 2:13 AM
To: notifications@jclouds.apache.org
Subject: [jira] [Created] (JCLOUDS-1205) Setting a custom pool name with 
floatingIpPoolNames() in NovaTemplateOptions seems to have no effect

Michael Militzer created JCLOUDS-1205:
-

 Summary: Setting a custom pool name with floatingIpPoolNames() in 
NovaTemplateOptions seems to have no effect
 Key: JCLOUDS-1205
 URL: https://issues.apache.org/jira/browse/JCLOUDS-1205
 Project: jclouds
  Issue Type: Bug
  Components: jclouds-compute
Affects Versions: 2.0.0
 Environment: CentOS 6.8, OpenJDK 1.8.0.111-0.b15.el6_8
Reporter: Michael Militzer


I'm trying to spawn an instance in the FUGA cloud (https://fuga.io/) with 
jclouds 2.0 and auto-associate a floating IP but this fails with:

{quote}
JavaException: org.jclouds.rest.ResourceNotFoundException: {"itemNotFound": 
{"message": "Floating IP pool not found.", "code": 404}}
{quote}

FUGA has a custom namespace for the FloatingIP extension and it uses a custom 
name for the Floating IP Pool. Because of the former, I already ran into 
https://issues.apache.org/jira/browse/JCLOUDS-1013 and had to update to jclouds 
2.0. With jclouds 2.0 this issue is solved and jclouds now finds the Floating 
IP extension but now the problem seems to be that jclouds does not use the 
right pool (with FUGA's custom pool name "external").

I'm using the generic compute service and my code to spawn a new instance looks 
somewhat like this:

{code}
ComputeService compute = 
this.contextBuilder.buildView(ComputeServiceContext.class).getComputeService();

try {
TemplateBuilder templateBuilder = compute.templateBuilder();
Template template = templateBuilder
.locationId(region)
.imageId(imageId)
.hardwareId(instanceType)
.build();

template.getOptions().as(NovaTemplateOptions.class).autoAssignFloatingIp(true);

template.getOptions().as(NovaTemplateOptions.class).floatingIpPoolNames("external");

template.getOptions().as(NovaTemplateOptions.class).userData(userData.getBytes());

NodeMetadata node = 
getOnlyElement(compute.createNodesInGroup(groupName, 1, template));
return node;

} catch (RunNodesException e) {
System.err.println("error adding node to group " + groupName + ": " + 
e.getMessage());
return null;
}
{code}

So I'm using the "floatingIpPoolNames" method in NovaTemplateOptions to specify 
FUGA's custom floating IP pool name "external". But still, trying to create an 
instance fails with the aforementioned exception:

{quote}
JavaException: org.jclouds.rest.ResourceNotFoundException: {"itemNotFound": 
{"message": "Floating IP pool not found.", "code": 404}}
{quote}

I believe the way I'm setting the custom pool name property via 
"floatingIpPoolNames" in NovaTemplateOptions must be basically correct. At 
least the "userData" I also set on NovaTemplateOptions just one line later is 
picked up correctly (verified when "autoAssignFloatingIp" is set to false, 
because then the instance is started successfully - just without a public IP, 
obviously).

I can successfully allocate and associate floating IPs to instances in the FUGA 
cloud when using horizon. And also with nova client I can successfully interact 
with the FUGA API to list the Floating IP Pools and to create/delete floating 
IPs:

{quote}
[xvid@devweb02 java]$ nova floating-ip-pool-list
WARNING: Command floating-ip-pool-list is deprecated and will be removed after 
Nova 15.0.0 is released. Use python-neutronclient or python-openstackclient 
instead.
+--+
| name |
+--+
| external |
+--+
[xvid@devweb02 java]$ nova floating-ip-create external
WARNING: Command floating-ip-create is deprecated and will be removed after 
Nova 15.0.0 is released. Use python-neutronclient or python-openstackclient 
instead.
+--++---+--+--+
| Id   | IP | Server Id | Fixed IP 
| Pool |
+--++---+--+--+
| 5a4a318e-1672-425d-9522-d900e34efa98 | 185.54.114.154 | - | -
| external |
+--++---+--+--+
[xvid@devweb02 java]$ nova floating-ip-list
WARNING: Command floating-ip-list is deprecated and 

Re: [jclouds/jclouds-examples] update blobstore-basics to use 2.0.0 (#90)

[Zack Shoylev]

+1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/90#issuecomment-263264615

Re: [jclouds/jclouds] Updates the default template so live tests pass again. (#1041)

[Zack Shoylev]

Closed #1041.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1041#event-867287149

Re: [jclouds/jclouds] Updates the default template so live tests pass again. (#1041)

[Zack Shoylev]

merged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1041#issuecomment-262077668

Re: [jclouds/jclouds] Updates the default template so live tests pass again. (#1041)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -80,9 +80,9 @@ public OperatingSystem apply(final Image from) {
 is64Bit = matcher.group(2).equals("x64");
  }
   } else {
- if (imageName.contains("Red Hat EL")) {
+ if (imageName.contains("Red Hat")) {

Well, the imageName string changed from "EL" to "Enterprise Linux" at some 
point, which is why the match was failing, but I don't know the original 
reasoning for being that specific. Seems safe, though.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1041

Re: [jclouds/jclouds] Updates the default template so live tests pass again. (#1041)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -80,9 +80,9 @@ public OperatingSystem apply(final Image from) {
 is64Bit = matcher.group(2).equals("x64");
  }
   } else {
- if (imageName.contains("Red Hat EL")) {
+ if (imageName.contains("Red Hat")) {

Not completely sure about this one, though.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1041#pullrequestreview-9339328

[jclouds/jclouds] Updates the default template so live tests pass again. (#1041)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1041

-- Commit Summary --

  * Updates the default template so live tests pass again.

-- File Changes --

M 
apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/functions/ImageToOperatingSystem.java
 (4)
M 
compute/src/main/java/org/jclouds/compute/reference/ComputeServiceConstants.java
 (2)
M 
compute/src/test/java/org/jclouds/compute/internal/BaseTemplateBuilderLiveTest.java
 (2)
M 
providers/rackspace-cloudservers-us/src/main/java/org/jclouds/rackspace/cloudservers/us/CloudServersUSProviderMetadata.java
 (2)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1041.patch
https://github.com/jclouds/jclouds/pull/1041.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1041

Re: [jclouds/jclouds] Missing cleanup was causing testReplaceManifest to fail (#1038)

[Zack Shoylev]

Closed #1038.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1038#event-859780341

Re: [jclouds/jclouds] Missing cleanup was causing testReplaceManifest to fail (#1038)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -117,6 +118,7 @@ public void 
> testDeleteSinglePartObjectWithMultiPartDelete() throws Exception {
  assertThat(resp.deleted()).isZero();
  assertThat(resp.notFound()).isZero();
  assertThat(resp.errors()).hasSize(1);
+ api.getObjectApi(regionId, containerName).delete(objectName);

Cleanup after the test suite takes care of it if it fails, but unfortunately 
other tests here (testreplacemanifest) will fail if it is not cleaned up on 
success.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1038

Re: [jclouds/jclouds] Missing cleanup was causing testReplaceManifest to fail (#1038)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -117,6 +118,7 @@ public void 
> testDeleteSinglePartObjectWithMultiPartDelete() throws Exception {
  assertThat(resp.deleted()).isZero();
  assertThat(resp.notFound()).isZero();
  assertThat(resp.errors()).hasSize(1);
+ api.getObjectApi(regionId, containerName).delete(objectName);

Yeah, otherwise cleanup takes care of it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1038

[jclouds/jclouds] Missing cleanup was causing testReplaceManifest to fail (#1038)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1038

-- Commit Summary --

  * Missing cleanup was causing testReplaceManifest to fail

-- File Changes --

M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/StaticLargeObjectApiLiveTest.java
 (4)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1038.patch
https://github.com/jclouds/jclouds/pull/1038.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1038

Re: [jclouds/jclouds] Use temporary file for Swift test inputs (#1035)

[Zack Shoylev]

+1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1035#issuecomment-259701113

Re: [jclouds/jclouds] Include part size in listMultipartUpload result (#1037)

[Zack Shoylev]

+1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1037#issuecomment-259492719

[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent

[Zack Shoylev (JIRA)]

[ 
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(S

[jira] [Closed] (JCLOUDS-1176) Swift delete operation is not idempotent

[Zack Shoylev (JIRA)]

 [ 
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.r

[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent

[Zack Shoylev (JIRA)]

[ 
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(S

Re: [jclouds/jclouds] fix jclouds/apis/swift retryOnRenew (#1027)

[Zack Shoylev]

@nacx I have had some issues reproducing 1176. But I think this is alright to 
merge even if it does not fix it right away (but I strongly suspect it will).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1027#issuecomment-256764753

Re: [jclouds/jclouds] filesystem: Modify the backslash only on Windows (#1029)

[Zack Shoylev]

Closed #1029.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1029#event-837932605

Re: [jclouds/jclouds] filesystem: Modify the backslash only on Windows (#1029)

[Zack Shoylev]

merged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1029#issuecomment-256518330

Re: [jclouds/jclouds] Remove PackageLocation check (#1030)

[Zack Shoylev]

Closed #1030.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1030#event-837931367

Re: [jclouds/jclouds] filesystem: Modify the backslash only on Windows (#1029)

[Zack Shoylev]

@zack-shoylev pushed 1 commit.

369caa0  review fix


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/jclouds/jclouds/pull/1029/files/704cbbde0aad4c3a117b6540a8b3bdc3e06a6f06..369caa037d4bff344a132221bfb653d51e053752

Re: [jclouds/jclouds] Remove PackageLocation check (#1030)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -878,7 +879,7 @@
   
 com.google.errorprone
 error_prone_core
-2.0.5
+2.0.13

Ah, right.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1030

Re: [jclouds/jclouds] Remove PackageLocation check (#1030)

[Zack Shoylev]

@zack-shoylev pushed 1 commit.

c01f796  Review fixes


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/jclouds/jclouds/pull/1030/files/ca977459e2e468ad44a729ed7ac78716b86c3af6..c01f7961beb0664448f7cb47c363f1531ff882d6

Re: [jclouds/jclouds] Remove PackageLocation check (#1030)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -807,7 +807,8 @@
   -Xep:NonCanonicalStaticImport:ERROR
   -Xep:NonFinalCompileTimeConstant:ERROR
   -Xep:Overrides:ERROR
-  -Xep:PackageLocation:ERROR
+  

Yep

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1030

Re: [jclouds/jclouds] Remove PackageLocation check (#1030)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -807,7 +807,8 @@
   -Xep:NonCanonicalStaticImport:ERROR
   -Xep:NonFinalCompileTimeConstant:ERROR
   -Xep:Overrides:ERROR
-  -Xep:PackageLocation:ERROR
+  
+  

I tried, but it says it cannot be disabled. Setting it to OFF or WARNING does 
not work.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1030

Re: [jclouds/jclouds] Update errorprone version (#1030)

[Zack Shoylev]

@andrewgaul  I'll repurpose this PR to taking out the PackageLocation check, 
then? Seems to work fine without it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1030#issuecomment-256490757

Re: [jclouds/jclouds] Update errorprone version (#1030)

[Zack Shoylev]

Ah, I see.

If I am reading this correctly, it's the PackageLocation one.

error-prone version: 2.0.5
  Stack Trace:
  java.nio.file.InvalidPathException: Illegal char <:> at index 2: 
/C:/programming/projects/jclouds/apis/filesystem/src/main/java/org/jclouds/filesystem/reference/FilesystemConstants.java
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
at java.nio.file.Paths.get(Paths.java:84)
at 
com.google.errorprone.bugpatterns.PackageLocation.getFilePath(PackageLocation.java:77)
at 
com.google.errorprone.bugpatterns.PackageLocation.matchCompilationUnit(PackageLocation.java:58)
at 
com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:594)
at 
com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:142)
at 
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:563)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:53)
at com.google.errorprone.scanner.Scanner.scan(Scanner.java:70)
at 
com.google.errorprone.scanner.ErrorProneScannerTransformer.apply(ErrorProneScannerTransformer.java:45)
at 
com.google.errorprone.ErrorProneAnalyzer.reportReadyForAnalysis(ErrorProneAnalyzer.java:151)
at 
com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:115)
at 
com.google.errorprone.ErrorProneJavacJavaCompiler.postFlow(ErrorProneJavacJavaCompiler.java:123)
at 
com.google.errorprone.ErrorProneJavacJavaCompiler.flow(ErrorProneJavacJavaCompiler.java:97)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1262)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:859)
at com.sun.tools.javac.main.Main.compile(Main.java:249)
at 
com.google.errorprone.ErrorProneCompiler.run(ErrorProneCompiler.java:249)
at 
com.google.errorprone.ErrorProneCompiler.run(ErrorProneCompiler.java:159)
at 
com.google.errorprone.ErrorProneCompiler.compile(ErrorProneCompiler.java:88)
at 
org.codehaus.plexus.compiler.javac.errorprone.JavacCompilerWithErrorProne$CompilerInvoker.compile(JavacCompilerWithErrorProne.java:219)
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:498)
at 
org.codehaus.plexus.compiler.javac.errorprone.JavacCompilerWithErrorProne.performCompile(JavacCompilerWithErrorProne.java:91)
at 
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785)
at 
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
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:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 

[jclouds/jclouds] Update errorprone version (#1030)

[Zack Shoylev]

The new errorprone checks break the build on Windows, for example: 
https://github.com/google/error-prone/issues/432

However, some additional fixes are needed to update the errorprone version.
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1030

-- Commit Summary --

  * Update errorprone version

-- File Changes --

M project/pom.xml (2)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1030.patch
https://github.com/jclouds/jclouds/pull/1030.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1030

[jclouds/jclouds] filesystem: Modify the backslash only on Windows (#1029)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1029

-- Commit Summary --

  * filesystem: Modify the backslash only on Windows

-- File Changes --

M 
apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java
 (11)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1029.patch
https://github.com/jclouds/jclouds/pull/1029.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1029

Re: [jclouds/jclouds] fix jclouds/apis/swift retryOnRenew (#1027)

[Zack Shoylev]

Good change! Thanks, @andreaturli 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1027#issuecomment-256479800

Re: [jclouds/jclouds] fix jclouds/apis/swift retryOnRenew (#1027)

[Zack Shoylev]

test408ShouldRetry for 2.0 should also be updated, it seems?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1027#issuecomment-256479071

Re: [jclouds/jclouds] fix jclouds/apis/swift retryOnRenew (#1027)

[Zack Shoylev]

This might affect https://issues.apache.org/jira/browse/JCLOUDS-1176

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1027#issuecomment-256475005

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

zack-shoylev commented on this pull request.



>  * @return
 */
-   private static String normalize(String pathToBeNormalized) {
-  if (null != pathToBeNormalized && 
pathToBeNormalized.contains(BACK_SLASH)) {
- if (!BACK_SLASH.equals(File.separator)) {
-return pathToBeNormalized.replace(BACK_SLASH, File.separator);
- }
+   private static String normalize(String path) {
+  if (null != path) {

But then it is not cross-platform. I mean, it's fairly easy to put the 
exception in, but a real fix will probably be somewhat more complex (i.e. 
hex-encoding the blob name). But I do get we want to keep this a filesystem 
provider, so it makes sense to have it follow the filesystem closely. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

Closed #1024.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024#event-836239845

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

merged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024#issuecomment-256195424

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

zack-shoylev commented on this pull request.



>  * @return
 */
-   private static String normalize(String pathToBeNormalized) {
-  if (null != pathToBeNormalized && 
pathToBeNormalized.contains(BACK_SLASH)) {
- if (!BACK_SLASH.equals(File.separator)) {
-return pathToBeNormalized.replace(BACK_SLASH, File.separator);
- }
+   private static String normalize(String path) {
+  if (null != path) {

I think it is better to treat both \ and / as path separators everywhere. This 
way people won't be getting unexpected results and they also won't have to 
write different code for Windows and Linux, which is what they would have to do 
if we treat \ differently. Keeps our code simpler, too. Thoughts, 
counterexamples?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

@zack-shoylev pushed 1 commit.

0347f57  review fixes


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/jclouds/jclouds/pull/1024/files/597fdfb78757fccb71bc4744146d5544bcaab3c6..0347f57bad28bbc2b9567c08a77ee62b213d9c17

Re: [jclouds/jclouds] Use file.separator in tests instead of slash (#1021)

[Zack Shoylev]

https://github.com/jclouds/jclouds/pull/1024

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1021#issuecomment-255812343

Re: [jclouds/jclouds] Use file.separator in tests instead of slash (#1021)

[Zack Shoylev]

Closed #1021.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1021#event-834256009

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> }
 
-   private static String denormalize(String pathToDenormalize) {
-  if (null != pathToDenormalize && pathToDenormalize.contains("/")) {
- if (BACK_SLASH.equals(File.separator)) {
-  return pathToDenormalize.replace("/", BACK_SLASH);
- }
+   /**
+* Convert path to jclouds standard (/)
+*/
+   private static String denormalize(String path) {
+  if (null != path) {
+ return path.replace("\\", "/");

I rather keep these rules OS-agnostic. Does this make sense?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024

Re: [jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

zack-shoylev commented on this pull request.



>  * @return
 */
-   private static String normalize(String pathToBeNormalized) {
-  if (null != pathToBeNormalized && 
pathToBeNormalized.contains(BACK_SLASH)) {
- if (!BACK_SLASH.equals(File.separator)) {
-return pathToBeNormalized.replace(BACK_SLASH, File.separator);
- }
+   private static String normalize(String path) {
+  if (null != path) {

This will also normalize the path on a Linux system, so I would rather leave it 
as is

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024

[jclouds/jclouds] Ensure that jclouds filesystem provider consistently uses / (#1024)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1024

-- Commit Summary --

  * Ensure that jclouds consistently uses /, works with \\, and uses 
File.separator on the filesystem level.

-- File Changes --

M 
apis/filesystem/src/main/java/org/jclouds/filesystem/predicates/validators/internal/FilesystemBlobKeyValidatorImpl.java
 (7)
M 
apis/filesystem/src/main/java/org/jclouds/filesystem/predicates/validators/internal/FilesystemContainerNameValidatorImpl.java
 (7)
M 
apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java
 (44)
M 
apis/filesystem/src/test/java/org/jclouds/filesystem/FilesystemBlobStoreTest.java
 (40)
M 
apis/filesystem/src/test/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImplTest.java
 (4)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1024.patch
https://github.com/jclouds/jclouds/pull/1024.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1024

Re: [jclouds/jclouds] Use file.separator in tests instead of slash (#1021)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -584,12 +584,12 @@ public void testListMarkerPrefix() throws Exception {
   final String container = getContainerName();
   try {
  blobStore.createContainerInLocation(null, container);
- blobStore.putBlob(container, 
blobStore.blobBuilder("a/a").payload("").build());
- blobStore.putBlob(container, 
blobStore.blobBuilder("b/b").payload("").build());
- ListContainerOptions options = new 
ListContainerOptions().afterMarker("b/").recursive();
+ blobStore.putBlob(container, blobStore.blobBuilder("a" + 
File.separator + "a").payload("").build());

Valid point. I'll look into it some more tomorrow.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1021

[jclouds/jclouds] Use file.separator in tests instead of slash (#1021)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1021

-- Commit Summary --

  * Use file.separator in tests instead of slash

-- File Changes --

M 
blobstore/src/test/java/org/jclouds/blobstore/integration/internal/BaseContainerIntegrationTest.java
 (8)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1021.patch
https://github.com/jclouds/jclouds/pull/1021.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1021

Re: [jclouds/jclouds] JCLOUDS-1179 This also addresses the same problem with other providers (#1018)

[Zack Shoylev]

merged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1018#issuecomment-253578451

Re: [jclouds/jclouds] JCLOUDS-1179 This also addresses the same problem with other providers (#1018)

[Zack Shoylev]

Closed #1018.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1018#event-822829025

[jira] [Resolved] (JCLOUDS-1179) putBlob doesn't handle 401s

[Zack Shoylev (JIRA)]

 [ 
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

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

[ 
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)

Re: [jclouds/jclouds] JCLOUDS-1179 This also addresses the same problem with other providers (#1018)

[Zack Shoylev]

https://issues.apache.org/jira/browse/JCLOUDS-1179

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1018#issuecomment-253019605

[jclouds/jclouds] JCLOUDS-1179 This also addresses the same problem with other providers (#1018)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1018

-- Commit Summary --

  * JCLOUDS-1179 This also addresses the same problem with other providers

-- File Changes --

M 
apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/ObjectApiMockTest.java
 (71)
A apis/openstack-swift/src/test/resources/access2.json (249)
M 
core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java
 (11)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1018.patch
https://github.com/jclouds/jclouds/pull/1018.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1018

[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

[ 
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)

Re: [jclouds/jclouds] Remove hardcoded content size for personality in Openstack Nova (#1012)

[Zack Shoylev]

I wouldn't be opposed, though I don't think refactoring old code to remove such 
checks is strictly necessary or high priority (unless actually needed).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1012#issuecomment-249673790

Re: [jclouds/jclouds] Add keystone authentication with an existing token (#1009)

[Zack Shoylev]

zack-shoylev commented on this pull request.



> @@ -234,6 +234,13 @@ public String get() {
   return authenticationMethods.get(credentialType);
}
 
+   @Provides
+   @Singleton
+   @Named("credentialsRetryable")
+   protected final boolean credentialsRetryable(Function<Credentials, Access> 
getAccess) {

So the code could directly check the type of credentials provided instead of 
relying on the boolean? Makes sense.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1009

Re: [jclouds/jclouds] Remove hardcoded content size for personality in Openstack Nova (#1012)

[Zack Shoylev]

This is a good change. We should be moving toward server-side validation in 
general.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1012#issuecomment-249228831

Re: [jclouds/jclouds] Add keystone authentication with an existing token (#1009)

[Zack Shoylev]

@olivierlemasle 

Yes, the code will still be quite useful for a few situations! I mostly wanted 
to add a comment to the code to ensure the limitations are documented. As for 
the tests, I think at least unit tests would be nice. For live tests, you can 
use devstack to test locally, but let's get the unit tests done first.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1009#issuecomment-248720659

[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

[ 
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

[Zack Shoylev (JIRA)]

[ 
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(S

Re: [jclouds/jclouds] More fixes to parallel download resource cleanup (#1010)

[Zack Shoylev]

merged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1010#issuecomment-247129173

Re: [jclouds/jclouds] More fixes to parallel download resource cleanup (#1010)

[Zack Shoylev]

Closed #1010.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1010#event-789701771

Re: [jclouds/jclouds] More fixes to parallel download resource cleanup (#1010)

[Zack Shoylev]

@nacx 1176: I will try to do a separate PR for it (out of scope for this one).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1010#issuecomment-247083691

Re: [jclouds/jclouds] More fixes to parallel download resource cleanup (#1010)

[Zack Shoylev]

@zack-shoylev pushed 1 commit.

c18747d  review fixes


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/jclouds/jclouds/pull/1010/files/304c72c3e24e376cebbb98bd3b8f8ad6ecd72dac..c18747de0aeb80b3a6ab9eae5c6ceddf6c8e3a1a