The turnaround time on this is INCREDIBLE!! :+1:
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/285#issuecomment-34685027
+ private int retryCountLimit = 5;
+ @Resource
+ protected Logger logger = Logger.NULL;
+
+ public boolean shouldRetryRequest(HttpCommand command, HttpResponse
response) {
+ if (command.getFailureCount() retryCountLimit) {
+ return false;
+ }
+ if
I tried varying the number of threads from 10 to 50 and deleting a container
with at least 5K blobs. Things worked fine. I'll rebase this patch on top of
the current ToT and send out.
---
Reply to this email directly or view it on GitHub:
I am trying to reproduce this locally. I have run 50 iterations of this test
so far, but haven't been able to reproduce the problem.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/214#issuecomment-36681788
Looks good to me.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/317#issuecomment-37567286
+ // If a future to delete a blob/directory actually got created
above,
+ // keep a reference of that in the outstandingFutures list. This is
+ // useful in case of a timeout exception. All outstanding futures
can
+ // then be cancelled.
+ if
import com.google.common.util.concurrent.ListenableFuture;
import com.google.common.util.concurrent.ListeningExecutorService;
import com.google.inject.Inject;
/**
* Deletes all keys in the container
- *
+ *
* @author Adrian Cole
Done
---
Reply to this email directly or view
+ * a timeout. Also, when the reference is removed from this list and
when
+ * the executorService removes the reference that it has maintained,
the
+ * future will be marked for GC since there should be no other
references
+ * to it. This is important because
+ listing = blobStore.list(containerName, options);
+ } catch (ContainerNotFoundException ce) {
+ return listing;
+ }
+
+ // recurse on subdirectories
+ if (options.isRecursive()) {
+ for (StorageMetadata md : listing) {
+String
+ String marker = listing.getNextMarker();
+ if (marker != null) {
+logger.debug(%s with marker %s, message, marker);
+options = options.afterMarker(marker);
+listing = getListing(containerName, options, semaphore,
+
Looks like a network glitch on cloudbees.
code
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not clone
git://github.com/jclouds/jclouds.git
...
stderr: fatal: unable to connect to github.com:
github.com[0: 192.30.252.129]: errno=Connection timed out
/code
Can
@@ -87,7 +87,9 @@ public void testListContainers() throws Exception {
public void testCreateContainer() throws Exception {
boolean created = false;
while (!created) {
- privateContainer = prefix + new SecureRandom().nextInt();
+
+ privateContainer =
@@ -87,7 +87,9 @@ public void testListContainers() throws Exception {
public void testCreateContainer() throws Exception {
boolean created = false;
while (!created) {
- privateContainer = prefix + new SecureRandom().nextInt();
+
+ privateContainer =
Do we know what's missing in the new implementation (in jclouds-labs-openstack)
that is present in the old implementation? In other words, what's the effort
required to have feature parity between the new implementation and the old one?
---
Reply to this email directly or view it on GitHub:
Congratulations on your first commit to jclouds @hsbhathiya. Looking forward to
more :-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/336#issuecomment-39277522
This commit looks good to me. +1.
I haven't seen too many uses of the getConsistencyModel API. I agree though,
that it seems useful.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/343#issuecomment-40336557
You can merge this Pull Request by running:
git pull https://github.com/maginatics/jclouds deleteallkeys-cleanup
Or you can view, comment on it, or merge it online at:
https://github.com/jclouds/jclouds/pull/349
-- Commit Summary --
* Create a separate function to delete directories.
Looks good to me too!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/348#issuecomment-40762944
Apart from what @andrewgaul said, we should have a unit test for this.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/338#issuecomment-40763386
Your're right. This is a purely refactoring commit.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/349#issuecomment-40847919
@@ -177,6 +177,26 @@ private String getMessage(final String containerName,
return listing;
}
+ private ListenableFutureVoid deleteDirectory(
Done.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/349/files#r11788434
Trying to fix this without knowing the root-cause does seems like a bad idea to
me. We may just hit this again in some other environment and/or in some other
circumstances and then this change simply lands up being dead code.
---
Reply to this email directly or view it on GitHub:
I see. The change itself looks fine to me.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/351#issuecomment-41104636
I definitely want to fix these test. I'll see if I can run the tests later
tonight.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/351#issuecomment-41106560
Even if we separate it, a signedGet will require a blob to present in the
container, right? This will require putting a blob and then trying to read it
using a signed url. Instead this commit uses a single test to do a signed put
first followed by a signed get.
---
Reply to this email directly
+ final ByteSource input = ByteSource.wrap(new byte[1]);
+ final HttpClient client = ctx.utils().http();
+
+ // test signed put
+ String blobName = test- + UUID.randomUUID();
+ Blob blob2 = region.blobBuilder(blobName).forSigning()
+
+
+ // test signed put
+ String blobName = test- + UUID.randomUUID();
+ Blob blob2 = region.blobBuilder(blobName).forSigning()
+ .payload(input).contentLength(input.size())
+ .contentMD5(input.hash(Hashing.md5()).asBytes())
+
HttpRequest request =
ctx.signerInRegion(regionId).signGetBlob(containerName, blobName);
assertNotNull(request, regionId= + regionId + , container= +
containerName + , blob= + blobName);
+ response = client.invoke(request);
+
+
+ // test signed put
+ String blobName = test- + UUID.randomUUID();
+ Blob blob2 = region.blobBuilder(blobName).forSigning()
+ .payload(input).contentLength(input.size())
+ .contentMD5(input.hash(Hashing.md5()).asBytes())
+
@@ -83,13 +94,29 @@ public void trySign() throws InterruptedException,
ExecutionException {
continue;
}
String containerName = Iterables.getLast(containers).getName();
- PageSet? extends StorageMetadata blobs =
region.list(containerName);
-
- String blobName = Iterables.getLast(blobs).getName();
+
+ final ByteSource input = ByteSource.wrap(new byte[1]);
+ final HttpClient client = ctx.utils().http();
+
+ // test signed put
+ String blobName = test- + UUID.randomUUID();
+ Blob
@@ -83,13 +94,29 @@ public void trySign() throws InterruptedException,
ExecutionException {
continue;
}
String containerName = Iterables.getLast(containers).getName();
- PageSet? extends StorageMetadata blobs =
region.list(containerName);
-
The change itself looks good. Can we have a unit test for this?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/368#issuecomment-43235344
Duh... nevermind then! :-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/368#issuecomment-43424762
Looks good to me.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/382#issuecomment-44369485
@@ -303,13 +303,15 @@ Options can also be specified for extension modules
blob-builder (if content-length ;; Special case, arg is prim.
(.contentLength blob-builder content-length)
blob-builder)
+ blob-builder (if
Hey Chris,
Thanks for adding support for the 13.5 API. Could you list some points (maybe
in the commit message itself) about what the actual changes are? Will make it
easier to understand the code changes.
---
Reply to this email directly or view it on GitHub:
+
+ // test signed get
+ try {
+HttpRequest getRequest = signer.signGetBlob(containerName,
+ blobName);
+assertNotNull(getRequest, regionId= + regionId + , container=
+ + containerName + , blob= + blobName);
+
+ .addHeader(HttpHeaders.CONTENT_TYPE,
+metadata.getContentType());
+putRequestBuilder.addHeader(HttpHeaders.CONTENT_LENGTH,
+ String.valueOf(input.size()));
+putRequestBuilder.payload(input);
+
+HttpRequest getRequest = signer.signGetBlob(containerName,
+ blobName);
+assertNotNull(getRequest, regionId= + regionId + , container=
+ + containerName + , blob= + blobName);
+response = client.invoke(getRequest);
+
Is there anything else that needs to be done here?
There is one feature that I am developing in jclouds that is made easier
because of this change. Let me know if there's anything I can do to help make
progress on this.
---
Reply to this email directly or view it on GitHub:
Reauthenticate on HTTP 401. Orig commit:
578a77d6313ce0945f8d29e82103e09787622c58
Closes #589.
You can merge this Pull Request by running:
git pull https://github.com/maginatics/jclouds
fix_401_unauthorized_non_keystone
Or you can view, comment on it, or merge it online at:
These are related to the change I made. I'll take a look and update the review
request.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/399#issuecomment-45554781
@Inject(optional = true)
@Named(Constants.PROPERTY_MAX_RETRIES)
- private int retryCountLimit = 5;
+ static final int NUM_RETRIES = 5;
@andrewgaul Done.
@zack-shoylev There is already a test for this. test401ShouldRetry4Times().
---
Reply to this email directly or view it on
@@ -60,6 +67,16 @@ protected RetryOnRenew(LoadingCacheCredentials, Auth
authenticationResponseCac
this.backoffHandler = backoffHandler;
}
+ /*
+* The reason retries need to be tracked is that it is possible that a
token
+* * can be expired at any time. The reason
I like the BlahAndClose methods. Makes code reading easier and using these
methods is less error prone.
I'm still a little fuzzy about about MultiPartForm gets used in the context of
other blobstore operations. But the change itself seems to do what is says.
Looks good!
---
Reply to this
deleteContainerIfEmpty seems useful. However, I'm not sure about deprecating
deleteContainer itself. I think of deleteContainerIfEmpty as rm and
deleteContainer as rm -rf. Both are useful.
---
Reply to this email directly or view it on GitHub:
@@ -272,10 +274,10 @@ public void deleteContainerWithContents() throws
InterruptedException {
String containerName = getContainerName();
try {
addBlobToContainer(containerName, test);
- view.getBlobStore().deleteContainer(containerName);
-
This change itself looks good to me.
Let's have a separate discussion about whether to deprecate deleteContainer.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/451#issuecomment-49951167
S3 compatible blobStores sometimes return date in the format:
quot;2014-07-23T20:53:17+quot; instead of the more common
quot;2014-07-23T18:09:39.944Zquot;. This caused jclouds to barf with an
IllegalArgumentException.
This commit tries to parse both the formats for S3. The exception
is thrown
@@ -51,7 +51,17 @@ public void endElement(String uri, String name, String
qName) {
if (qName.equals(ETag)) {
this.currentETag = currentOrNull(currentText);
} else if (qName.equals(LastModified)) {
- this.currentLastModified =
Thanks for pushing this to master @andrewgaul. I believe the jclouds 1.8.0
release next week will be based off of master so this fix will make it there.
Do we need to backport this fix to the 1.7.x branch for any further 1.7.x
releases?
---
Reply to this email directly or view it on GitHub:
-### Multipart upload
-
-Providers may implement multipart upload for large or very files.
-Here's an example of `multipart upload` using aws-s3 provider, which [allow
uploading files large as
5TB.](http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?qfacts.html)
Closed #220.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/220#event-147810874
Closed #239.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/239#event-147810983
+* TODO
+
+## a id=issues/aKnown Issues
+
+* TODO
+
+## a id=reminder/aReminder
+
+The jclouds Maven group ID for versions since [1.6.1-incubating](../1.6.1)
is `org.apache.jclouds` rather than `org.jclouds`, so a pom.xml dependency
would now look like:
+
+{% highlight xml %}
+1. [Highlights](#highlights)
+1. [API Changes](#api)
+1. [Known Issues](#issues)
+1. [Reminder](#reminder)
+1. [Credits](#credits)
+1. [Test Results](#test)
+
+## a id=intro/aIntroduction
+
+You can read the official announcement at TODO ([Apache jclouds 1.7.3
.addHeader(Date,
CONSTANT_DATE)
- .addHeader(Authorization,
AWS identity:p32RsBr2inawMBeCkkiA228BT2w=)
Why was the change in identity needed?
---
Reply to this email directly or view it on GitHub:
.addHeader(Date,
CONSTANT_DATE)
- .addHeader(Authorization,
AWS identity:p32RsBr2inawMBeCkkiA228BT2w=)
I see.
---
Reply to this email directly or view it on GitHub:
Change looks good to me.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/475#issuecomment-51816730
Sorry I missed this earlier. I will take a look at this later today.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/465#issuecomment-51953773
currentName = currentText.toString().trim();
- if (currentName.equals())
-currentName = null;
+ } else if (qName.equals(Value)) {
+ if (currentName.equals(size)) {
The way you have it, size is in the correct case as per
Generally, looks good. I'll take a look again when other concerns are addressed.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/465#issuecomment-5199
Not sure what to make of the failures above. The checkstyle violations are not
in my commit. Apparently they are in the neutron-api that I have not touched.
Any ideas?
---
Reply to this email directly or view it on GitHub:
Fix unit tests accordingly.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/1008
-- Commit Summary --
* JCLOUDS-1161: Make AWSS3BlobRequestSignerV4 the default signer.
-- File Changes --
M
Do the live tests run successfully on current master? The same 4 tests above
failed for me on current master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Added a new live test, specifically run against eu-central-1 region.
--
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/1008#issuecomment-246511656
Thanks for fixing the tests on master @andrewgaul. I am able to run the tests
successfully on master and also able to reproduce the test failures with my
change. I'll fix them and upload a new commit.
--
You are receiving this because you commented.
Reply to this email directly or view it on
[
https://issues.apache.org/jira/browse/JCLOUDS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886840#comment-13886840
]
Shri Javadekar commented on JCLOUDS-311:
FWIW, versionId, versionInfo
[
https://issues.apache.org/jira/browse/JCLOUDS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shri Javadekar updated JCLOUDS-510:
---
Description:
The current implementation of DeleteAllKeysInList suffers from the head
[
https://issues.apache.org/jira/browse/JCLOUDS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13962009#comment-13962009
]
Shri Javadekar commented on JCLOUDS-510:
This didn't make it into 1.7.2 because
[
https://issues.apache.org/jira/browse/JCLOUDS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shri Javadekar updated JCLOUDS-510:
---
Fix Version/s: (was: 1.7.2)
Head-of-line blocking problem with DeleteAllKeysInList
Shri Javadekar created JCLOUDS-589:
--
Summary: Port fix for JCLOUDS-178 to non-keystone-v2.0 auth
implementations
Key: JCLOUDS-589
URL: https://issues.apache.org/jira/browse/JCLOUDS-589
Project
Shri Javadekar created JCLOUDS-590:
--
Summary: Port fix for JCLOUDS-178 to non-keystone-v2.0 auth
implementations
Key: JCLOUDS-590
URL: https://issues.apache.org/jira/browse/JCLOUDS-590
Project
[
https://issues.apache.org/jira/browse/JCLOUDS-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14030052#comment-14030052
]
Shri Javadekar commented on JCLOUDS-598:
Thanks for filing this Andrew. I'll take
Shri Javadekar created JCLOUDS-628:
--
Summary: PROPERTY_MAX_CONNECTIONS_PER_CONTEXT not honored for
https connections
Key: JCLOUDS-628
URL: https://issues.apache.org/jira/browse/JCLOUDS-628
Project
[
https://issues.apache.org/jira/browse/JCLOUDS-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064033#comment-14064033
]
Shri Javadekar commented on JCLOUDS-628:
The JavaUrlHttpCommandExecutorService
[
https://issues.apache.org/jira/browse/JCLOUDS-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064033#comment-14064033
]
Shri Javadekar edited comment on JCLOUDS-628 at 7/21/14 5:56 PM
[
https://issues.apache.org/jira/browse/JCLOUDS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072121#comment-14072121
]
Shri Javadekar commented on JCLOUDS-635:
Pull request out for review: https
[
https://issues.apache.org/jira/browse/JCLOUDS-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076525#comment-14076525
]
Shri Javadekar commented on JCLOUDS-641:
We've running nightly tests using
Shri Javadekar created JCLOUDS-645:
--
Summary: Incorrect endpoint url chosen for default region of
HPCloud Object Storage
Key: JCLOUDS-645
URL: https://issues.apache.org/jira/browse/JCLOUDS-645
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081528#comment-14081528
]
Shri Javadekar commented on JCLOUDS-645:
HPCloudObjectStorageEndpointModule does
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081528#comment-14081528
]
Shri Javadekar edited comment on JCLOUDS-645 at 7/31/14 9:42 PM
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081567#comment-14081567
]
Shri Javadekar commented on JCLOUDS-645:
Apparently
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081773#comment-14081773
]
Shri Javadekar commented on JCLOUDS-645:
One difference that I find between
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081941#comment-14081941
]
Shri Javadekar commented on JCLOUDS-645:
Do you know what commit changed
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082626#comment-14082626
]
Shri Javadekar commented on JCLOUDS-645:
I agree with the larger point about
[
https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082663#comment-14082663
]
Shri Javadekar commented on JCLOUDS-645:
Unfortunately this is also affects
Shri Javadekar created JCLOUDS-648:
--
Summary: putBlob operation does not throw a
ContainerNotFoundException against Swift based blobstores
Key: JCLOUDS-648
URL: https://issues.apache.org/jira/browse/JCLOUDS-648
Shri Javadekar created JCLOUDS-650:
--
Summary: getBlob for non-existent containers does not throw a
ContainerNotFoundException
Key: JCLOUDS-650
URL: https://issues.apache.org/jira/browse/JCLOUDS-650
[
https://issues.apache.org/jira/browse/JCLOUDS-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085592#comment-14085592
]
Shri Javadekar commented on JCLOUDS-648:
This is so weird. Sometimes I get
Shri Javadekar created JCLOUDS-684:
--
Summary: Add option to delete containers without deleting objects
inside it
Key: JCLOUDS-684
URL: https://issues.apache.org/jira/browse/JCLOUDS-684
Project
[
https://issues.apache.org/jira/browse/JCLOUDS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shri Javadekar reopened JCLOUDS-684:
Great to know that jclouds already does the right thing for Azure.
However, an option
[
https://issues.apache.org/jira/browse/JCLOUDS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14109831#comment-14109831
]
Shri Javadekar edited comment on JCLOUDS-684 at 8/25/14 10:42 PM
Shri Javadekar created JCLOUDS-712:
--
Summary: ETAG Header with tempurls in the 'openstack-swift'
provider consistently results in a 503 Service unavailable response
Key: JCLOUDS-712
URL: https
[
https://issues.apache.org/jira/browse/JCLOUDS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126729#comment-14126729
]
Shri Javadekar commented on JCLOUDS-712:
[~jdaggett] Any ideas?
ETAG Header
[
https://issues.apache.org/jira/browse/JCLOUDS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127695#comment-14127695
]
Shri Javadekar commented on JCLOUDS-635:
To add to what [~gaul] said, if we
Shri Javadekar created JCLOUDS-727:
--
Summary: openstack-swift provider's BlobRequestSigner.signPutBlob
does not set payload and content lenght
Key: JCLOUDS-727
URL: https://issues.apache.org/jira/browse/JCLOUDS
[
https://issues.apache.org/jira/browse/JCLOUDS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shri Javadekar closed JCLOUDS-510.
--
Resolution: Fixed
Head-of-line blocking problem with DeleteAllKeysInList
[
https://issues.apache.org/jira/browse/JCLOUDS-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387535#comment-14387535
]
Shri Javadekar commented on JCLOUDS-874:
How was this working in jclouds-1.8.1
1 - 100 of 102 matches
Mail list logo
