Skip to content
This repository has been archived by the owner on Mar 25, 2018. It is now read-only.

Use ConcurrentSkipListMap for transient blobstore. #1565

Closed
wants to merge 1 commit into from
Closed

Use ConcurrentSkipListMap for transient blobstore. #1565

wants to merge 1 commit into from

Conversation

shrinandj
Copy link

The current implementation uses a ConcurrentHashMap for storing key value pairs in the Transient blobstore. LocalAsyncBlobStore.list has to fetch all the blobs from this map and then return a subset based on the marker. Instead this change uses a ConcurrentSkipListMap which has natural ordering and sends the marker down to TransientStorageStrategy for more efficient enumeration.

Fixes #1561.

@gaul
Copy link
Member

gaul commented Apr 24, 2013

+1

@buildhive
Copy link

Adrian Cole » jclouds #51 FAILURE
Looks like there's a problem with this pull request
(what's this?)

@cloudbees-pull-request-builder

jclouds-java-7-pull-requests #404 FAILURE
Looks like there's a problem with this pull request

@gaul
Copy link
Member

gaul commented Apr 24, 2013

Needs a similar change in filesystem blobstore, although note that Java 6 does not support resumable readdir.

@shrinandj
Copy link
Author

@adriancole : I like the idea of having overloaded getBlobKeysInsideContainer(). If callers don't care they need not pass the second argument. But I'd like callers to have the ability to pass null (in which case we fallback to using single-argument implementation). For e.g. the list() method in LocalAsyncBlobStore can pass options.getMarker() which may or may not be null.

Also, is it okay to do the renaming in a separate commit? It'll be easier to keep this one specific to bug 1561.

@andrewgaul : I don't understand what the filesystem blobstore has to do with BlockUntilInitScriptStatusIsZeroThenReturnOutputTest.testloopUntilTrueOrThrowCancellationExceptionReturnsWhenPredicateIsTrueSecondTimeWhileNotCancelled(). I ran this test locally and did not hit any assert.

@codefromthecrypt
Copy link
Contributor

well, typically we don't like null params at all. In the rare case we do,
we'd annotate it @Nullable. This is internal code, so I'm not going to
fuss.. that said, you mind adding the annotation?

On Wed, Apr 24, 2013 at 2:24 PM, Shri Javadekar [email protected]:

@adriancole https://github.com/adriancole : I like the idea of having
overloaded getBlobKeysInsideContainer(). If callers don't care they need
not pass the second argument. But I'd like callers to have the ability to
pass null (in which case we fallback to using single-argument
implementation). For e.g. the list() method in LocalAsyncBlobStore can pass
options.getMarker() which may or may not be null.

Also, is it okay to do the renaming in a separate commit? It'll be easier
to keep this one specific to bug 1561.

@andrewgaul https://github.com/andrewgaul : I don't understand what the
filesystem blobstore has to do with
BlockUntilInitScriptStatusIsZeroThenReturnOutputTest.testloopUntilTrueOrThrowCancellationExceptionReturnsWhenPredicateIsTrueSecondTimeWhileNotCancelled().
I ran this test locally and did not hit any assert.


Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/pull/1565#issuecomment-16966963
.

@demobox
Copy link
Member

demobox commented Apr 24, 2013

Just to repeat: same compilation failure in both builds

[ERROR] /scratch/jenkins/workspace/jclouds/jclouds/apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java:[59,7] org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImpl is not abstract and does not override abstract method getBlobKeysInsideContainer(java.lang.String,java.lang.String) in org.jclouds.blobstore.LocalStorageStrategy
[ERROR] /scratch/jenkins/workspace/jclouds/jclouds/apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java:[154,3] method does not override or implement a method from a supertype

and

[ERROR] /scratch/jenkins/workspace/jclouds-java-7-pull-requests/apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java:[59,7] error: FilesystemStorageStrategyImpl is not abstract and does not override abstract method getBlobKeysInsideContainer(String,String) in LocalStorageStrategy
[ERROR] /scratch/jenkins/workspace/jclouds-java-7-pull-requests/apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java:[154,3] error: method does not override or implement a method from a supertype

@shrinandj I think that's what @andrewgaul might be referring to...

@buildhive
Copy link

Adrian Cole » jclouds #53 SUCCESS
This pull request looks good
(what's this?)

@cloudbees-pull-request-builder

jclouds-java-7-pull-requests #406 SUCCESS
This pull request looks good

@codefromthecrypt
Copy link
Contributor

just helping answer this, as I can't necessarily promise I'll be online:

in which case the caller has to be check for null and make the appropriate API call. So that code would start looking difficult to read. The reason I think a library (like jclouds) should do these checks is because that way the code calling into this library is easier to read (which I presume is what jclouds' users want).

The context is whether or not to permit nulls as the argument to an overloaded method like this:

listBlobNamesStartingAt(String marker);

The assumption is that the code would look difficult to read if the caller were required to pass a non-null reference here. jclouds aims to be modeled based on principles described in books such as effective java and clean code. It is actually the clean code (implied as readable code) that suggests making commands which describe their arguments. While not totally put together, there are some things listed here to help understand principles we employ:
jclouds/legacy-jclouds.github.com#93
https://github.com/jclouds/jclouds.github.com/blob/master/documentation/devguides/guice-guava-primer.md

You won't find many guava methods to intentionally accept null parameters, especially if they are overloaded. Not only does the matter-of-course acceptance of null multiple the test burden of code, it also impacts readability. For example, you have to make some leap of faith to understand: "list blob names starting at null". While in jclouds, especially in old code, we have some args that have null, it is the outlier.

If you want to proceed down the track of helping us get more readable, I'd start with this pull request, and make it readable.

Then, you can start discussions of how allowing random fields to be null increases readability.

@jclouds
Copy link
Collaborator

jclouds commented Apr 25, 2013

p.s. the commentary is just that, and not a -1. Personally, I don't like
this change for quality reasons.

In general it bothers me when we accept code that lowers our quality and/or
test coverage.

That said, enumerating, explaining, or resolving the issues here will take
time I cannot budget for during our release crunch.

Hence, I'll abstain and defer to @gaul judgement who can merge this pr when
he feels it is right.

@buildhive
Copy link

Adrian Cole » jclouds #54 SUCCESS
This pull request looks good
(what's this?)

@cloudbees-pull-request-builder

jclouds-java-7-pull-requests #407 UNSTABLE
Looks like there's a problem with this pull request

}

List<String> blobNames = Lists.newArrayList();
if (!containerExists(container)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonky formatting. More three- and four-space indentation disagreements?

@gaul
Copy link
Member

gaul commented Apr 25, 2013

Can you add a small test which exercises marker?

@gaul
Copy link
Member

gaul commented Apr 25, 2013

I do not have a strong opinion on the Nullable comments. We can use Optional if we want to be explicit.

The current implementation uses a ConcurrentHashMap for storing key
value pairs in the Transient blobstore. LocalAsyncBlobStore.list has to
fetch all the blobs from this map and then return a subset based on
the marker. Instead this change uses a ConcurrentSkipListMap which has
natural ordering and sends the marker down to TransientStorageStrategy
for more efficient enumeration.

Fixes #1561.
@cloudbees-pull-request-builder

jclouds-java-7-pull-requests #408 SUCCESS
This pull request looks good

@buildhive
Copy link

Adrian Cole » jclouds #56 SUCCESS
This pull request looks good
(what's this?)

@shrinandj shrinandj closed this Jul 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enumerate blobs more efficiently in transient blobstore
7 participants