[GitHub] nacx opened a new pull request #2: PR build test. Do not merge
nacx opened a new pull request #2: PR build test. Do not merge URL: https://github.com/apache/jclouds-site/pull/2 PR build test. Do not merge This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] nacx closed pull request #2: PR build test. Do not merge
nacx closed pull request #2: PR build test. Do not merge URL: https://github.com/apache/jclouds-site/pull/2 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (JCLOUDS-1488) Filesystem list call with prefix is slow in large containers
[
https://issues.apache.org/jira/browse/JCLOUDS-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746537#comment-16746537
]
Andrew Gaul commented on JCLOUDS-1488:
--
I agree with your diagnosis and this is a long-standing shortcoming of the
filesystem provider. Could you submit a pull request with your proposed
solution? See also
[JCLOUDS-1371|https://issues.apache.org/jira/browse/JCLOUDS-1371].
> Filesystem list call with prefix is slow in large containers
>
>
> Key: JCLOUDS-1488
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1488
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
> Environment: Java version: java version "1.8.0_131"
> Operating system: Fedora 27 x86_64
>Reporter: Lari Sinisalo
>Priority: Major
> Labels: filesystem
> Attachments: JCLOUDS1488.java
>
>
> When the filesystem blobstore is used, running the following code takes very
> long if there are a lot of files in the container:
> {code:java}
> ListContainerOptions options = new ListContainerOptions();
> options.prefix("test-container-subdirectory/");
> Set results =
> blobStore.list("test-container",options);
> {code}
> See the attached Java source file [^JCLOUDS1488.java] for the full code.
> On my system, running the attached Java code takes over 10 seconds to list a
> single file if there are 500,000 files in the container outside that prefix.
> Output from the attached code:
> {code:java}
> Number of blobs listed: 1
> First listed blob: test-container-subdirectory/file-to-list
> Time it took to list the blobs: 13256 ms
> {code}
> A more general version of this problem was reported previously in
> JCLOUDS-1371.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [jclouds/jclouds] JCLOUDS-769: streaming putBlob (#1129)
Hm, I see where you're going.
The main issue I see with this approach is that a client won't know actually
when a streaming request has finished, and won't have access to the response
code, which might be important...
How are we handling streaming requests to endpoints return a redirect (3xx) we
should follow before posting the content?
Access to the response status is important, and that was one of my reasons to
suggest the specialized payload approach. My thinking was something like having
a specialised binding for, say, `Writer` parameters in API methods, and handle
that at the writer level by blocking until the writer is done, then completing
the method call and returning following the existing flows and response and
error handling mechanisms.
Something like:
```java
@Named("PutObject")
@PUT
@Path("/{key}")
@Headers(keys = EXPECT, values = "100-continue")
@ResponseParser(ReturnOutputStream.class)
ETagOutputStream putObjectStreaming(
@Bucket @EndpointParam(parser = AssignCorrectHostnameForBucket.class)
@BinderParam(BindAsHostPrefixIfConfigured.class)
@ParamValidators(BucketNameValidator.class) String bucketName,
@PathParam("key") @ParamParser(ObjectKey.class)
@BinderParam(BindS3ObjectMetadataToRequest.class) S3Object object,
Writer streamingContent, // This is an object the client controlls that
should be piped to the request outputstream
PutObjectOptions... options);
```
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/1129#issuecomment-455596882
Re: [jclouds/jclouds-labs] JCLOUDS-1407 Add dimensiondata server API v2.7 supportServer API 2.7 support (#447)
Also please rebase to make sure there are no conflicts. And apologies for the delay in the review. We've been busy with jclouds housekeeping stuff these months. -- 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-labs/pull/447#issuecomment-455590418
Re: [jclouds/jclouds-labs] JCLOUDS-1407 Add dimensiondata server API v2.7 supportServer API 2.7 support (#447)
nacx approved this pull request.
There are just minor and cosmetic comments. Model looks very good and clean.
Thanks!
I'll merge the PR as soon as comments are addressed.
> +import java.util.List;
+
+@AutoValue
+public abstract class IdeController {
+
+ public abstract String id();
+
+ public abstract int key();
+
+ public abstract int channel();
+
+ public abstract State state();
+
+ public abstract String adapterType();
+
+ @Nullable
This can never be null as per the builder.
> +import java.util.List;
+
+@AutoValue
+public abstract class SataController {
+
+ public abstract String id();
+
+ public abstract int key();
+
+ public abstract int busNumber();
+
+ public abstract State state();
+
+ public abstract String adapterType();
+
+ @Nullable
Can't be null given the builder.
> +import java.util.List;
+
+@AutoValue
+public abstract class ScsiController {
+
+ public abstract String id();
+
+ public abstract int key();
+
+ public abstract int busNumber();
+
+ public abstract State state();
+
+ public abstract String adapterType();
+
+ @Nullable
Remove.
> + public abstract Builder key(int key);
+
+ public abstract Builder busNumber(int busNumber);
+
+ public abstract Builder state(State state);
+
+ public abstract Builder adapterType(String adapterType);
+
+ abstract ScsiController autoBuild();
+
+ abstract List disks();
+
+ public abstract Builder disks(List disks);
+
+ public ScsiController build() {
+ disks(disks() != null ? ImmutableList.copyOf(disks()) : new
ArrayList());
Enforce an immutable list in all cases.
> @@ -60,10 +63,19 @@ public static Builder builder() {
public abstract int memoryGb();
@Nullable
- public abstract List disks();
+ public abstract NetworkInfo networkInfo();
+
+ @Nullable
Remove nullable annotations from all lists that have presence enforced in the
builder. Apply this pattern in general.
> @@ -61,7 +61,7 @@
@RequestFilters({ BasicAuthentication.class, OrganisationIdFilter.class })
@Consumes(MediaType.APPLICATION_JSON)
-@Path("/caas/{jclouds.api-version}/server")
+@Path("/caas/2.7/server")
I guess some domain model stuff is preventing us from upgrading all APIs?
--
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-labs/pull/447#pullrequestreview-194153973
[GitHub] nacx opened a new pull request #2: PR build test. Do not merge
nacx opened a new pull request #2: PR build test. Do not merge URL: https://github.com/apache/jclouds-site/pull/2 PR build test. Do not merge This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [jclouds/jclouds-labs] JCLOUDS-1486 - Fix NPE and Remove Nullable osImageKey From OsImage (#453)
Thanks @jawnclarke! Merged to master and 2.1.x. Please open further PRs in the [apache org repo](https://github.com/apache/jclouds-labs). -- 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-labs/pull/453#issuecomment-455582487
Re: [jclouds/jclouds-labs] JCLOUDS-1486 - Fix NPE and Remove Nullable osImageKey From OsImage (#453)
Closed #453. -- 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-labs/pull/453#event-2083184604
Re: [jclouds/jclouds-labs] JCLOUDS-1486 - Fix NPE and Remove Nullable osImageKey From OsImage (#453)
nacx approved this pull request. -- 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-labs/pull/453#pullrequestreview-194139976
[jira] [Commented] (JCLOUDS-1428) Support for SAS token based Authentication for Azure Blob Storage
[
https://issues.apache.org/jira/browse/JCLOUDS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746375#comment-16746375
]
Ignasi Barrera commented on JCLOUDS-1428:
-
{quote}
Anyway, I would be really glad someone could invite me to the jclouds slack
channel, as I have no access to the community.
{quote}
Done!
> Support for SAS token based Authentication for Azure Blob Storage
> -
>
> Key: JCLOUDS-1428
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1428
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Reporter: Himanshu Jain
>Priority: Major
> Labels: azureblob
>
> Hi,
> We have one use case where we want to provide limited access to objects in
> our storage accounts. We figured that the best way to do this is by using
> SAS token based authentication mechanism to upload/download objects to Azure
> Blob Storage - [SAS based
> Authentication|https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1]
> We found that JClouds client library provides support for Azure Blob Storage
> using account keys which might not fit our use case because of security
> reasons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCLOUDS-1488) Filesystem list call with prefix is slow in large containers
Lari Sinisalo created JCLOUDS-1488:
--
Summary: Filesystem list call with prefix is slow in large
containers
Key: JCLOUDS-1488
URL: https://issues.apache.org/jira/browse/JCLOUDS-1488
Project: jclouds
Issue Type: Bug
Components: jclouds-blobstore
Affects Versions: 2.1.1
Environment: Java version: java version "1.8.0_131"
Operating system: Fedora 27 x86_64
Reporter: Lari Sinisalo
When the filesystem blobstore is used, running the following code takes very
long if there are a lot of files in the container:
{code}
ListContainerOptions options = new ListContainerOptions();
options.prefix("test-container-subdirectory/");
Set results =
blobStore.list("test-container",options);
{code}
See the attached Java source file for the full code.
On my system, running the attached Java code takes over 10 seconds to list a
single file if there are 500,000 files in the container outside that prefix.
Output from the attached code:
{code}
Number of blobs listed: 1
First listed blob: test-container-subdirectory/file-to-list
Time it took to list the blobs: 13256 ms
{code}
A more general version of this problem was reported previously in JCLOUDS-1371.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1488) Filesystem list call with prefix is slow in large containers
[
https://issues.apache.org/jira/browse/JCLOUDS-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746126#comment-16746126
]
Lari Sinisalo commented on JCLOUDS-1488:
In org.jclouds.blobstore.config.LocalBlobStore.list(String,
ListContainerOptions), there is the following code:
{code}
// Loading blobs from container
Iterable blobBelongingToContainer = null;
try {
blobBelongingToContainer =
storageStrategy.getBlobKeysInsideContainer(containerName);
} catch (IOException e) {
logger.error(e, "An error occurred loading blobs contained into container
%s", containerName);
propagate(e);
}
{code}
This getBlobKeysInsideContainer lists the keys of all blobs inside the
container. It takes only the container name as a parameter, so it will always
ignore the prefix in the ListContainerOptions.
The getBlobKeysInsideContainer implementation in FilesystemStorageStrategyImpl
is as follows:
{code}
/**
* Returns all the blobs key inside a container
*
* @param container
* @return
* @throws IOException
*/
@Override
public Iterable getBlobKeysInsideContainer(String container) throws
IOException {
filesystemContainerNameValidator.validate(container);
// check if container exists
// TODO maybe an error is more appropriate
Set blobNames = Sets.newHashSet();
if (!containerExists(container)) {
return blobNames;
}
File containerFile = openFolder(container);
final int containerPathLength = containerFile.getAbsolutePath().length()
+ 1;
populateBlobKeysInContainer(containerFile, blobNames, new
Function() {
@Override
public String apply(String string) {
return denormalize(string.substring(containerPathLength));
}
});
return blobNames;
}
{code}
The openFolder call here opens the container root directory. It seems that if
this call would receive a subdirectory path instead, the list call would be
much more efficient.
I am not quite sure what would be the appropriate way to extract the
subdirectory path from the prefix. This would need to be done in a way that
does not allow path traversal outside the container root directory. Passing the
necessary information to getBlobKeysInsideContainer would also require
interface changes.
> Filesystem list call with prefix is slow in large containers
>
>
> Key: JCLOUDS-1488
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1488
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
> Environment: Java version: java version "1.8.0_131"
> Operating system: Fedora 27 x86_64
>Reporter: Lari Sinisalo
>Priority: Major
> Labels: filesystem
> Attachments: JCLOUDS1488.java
>
>
> When the filesystem blobstore is used, running the following code takes very
> long if there are a lot of files in the container:
> {code:java}
> ListContainerOptions options = new ListContainerOptions();
> options.prefix("test-container-subdirectory/");
> Set results =
> blobStore.list("test-container",options);
> {code}
> See the attached Java source file [^JCLOUDS1488.java] for the full code.
> On my system, running the attached Java code takes over 10 seconds to list a
> single file if there are 500,000 files in the container outside that prefix.
> Output from the attached code:
> {code:java}
> Number of blobs listed: 1
> First listed blob: test-container-subdirectory/file-to-list
> Time it took to list the blobs: 13256 ms
> {code}
> A more general version of this problem was reported previously in
> JCLOUDS-1371.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1488) Filesystem list call with prefix is slow in large containers
[
https://issues.apache.org/jira/browse/JCLOUDS-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lari Sinisalo updated JCLOUDS-1488:
---
Attachment: JCLOUDS1488.java
> Filesystem list call with prefix is slow in large containers
>
>
> Key: JCLOUDS-1488
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1488
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
> Environment: Java version: java version "1.8.0_131"
> Operating system: Fedora 27 x86_64
>Reporter: Lari Sinisalo
>Priority: Major
> Labels: filesystem
> Attachments: JCLOUDS1488.java
>
>
> When the filesystem blobstore is used, running the following code takes very
> long if there are a lot of files in the container:
> {code}
> ListContainerOptions options = new ListContainerOptions();
> options.prefix("test-container-subdirectory/");
> Set results =
> blobStore.list("test-container",options);
> {code}
> See the attached Java source file for the full code.
> On my system, running the attached Java code takes over 10 seconds to list a
> single file if there are 500,000 files in the container outside that prefix.
> Output from the attached code:
> {code}
> Number of blobs listed: 1
> First listed blob: test-container-subdirectory/file-to-list
> Time it took to list the blobs: 13256 ms
> {code}
> A more general version of this problem was reported previously in
> JCLOUDS-1371.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1488) Filesystem list call with prefix is slow in large containers
[
https://issues.apache.org/jira/browse/JCLOUDS-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lari Sinisalo updated JCLOUDS-1488:
---
Description:
When the filesystem blobstore is used, running the following code takes very
long if there are a lot of files in the container:
{code:java}
ListContainerOptions options = new ListContainerOptions();
options.prefix("test-container-subdirectory/");
Set results =
blobStore.list("test-container",options);
{code}
See the attached Java source file [^JCLOUDS1488.java] for the full code.
On my system, running the attached Java code takes over 10 seconds to list a
single file if there are 500,000 files in the container outside that prefix.
Output from the attached code:
{code:java}
Number of blobs listed: 1
First listed blob: test-container-subdirectory/file-to-list
Time it took to list the blobs: 13256 ms
{code}
A more general version of this problem was reported previously in JCLOUDS-1371.
was:
When the filesystem blobstore is used, running the following code takes very
long if there are a lot of files in the container:
{code}
ListContainerOptions options = new ListContainerOptions();
options.prefix("test-container-subdirectory/");
Set results =
blobStore.list("test-container",options);
{code}
See the attached Java source file for the full code.
On my system, running the attached Java code takes over 10 seconds to list a
single file if there are 500,000 files in the container outside that prefix.
Output from the attached code:
{code}
Number of blobs listed: 1
First listed blob: test-container-subdirectory/file-to-list
Time it took to list the blobs: 13256 ms
{code}
A more general version of this problem was reported previously in JCLOUDS-1371.
> Filesystem list call with prefix is slow in large containers
>
>
> Key: JCLOUDS-1488
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1488
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
> Environment: Java version: java version "1.8.0_131"
> Operating system: Fedora 27 x86_64
>Reporter: Lari Sinisalo
>Priority: Major
> Labels: filesystem
> Attachments: JCLOUDS1488.java
>
>
> When the filesystem blobstore is used, running the following code takes very
> long if there are a lot of files in the container:
> {code:java}
> ListContainerOptions options = new ListContainerOptions();
> options.prefix("test-container-subdirectory/");
> Set results =
> blobStore.list("test-container",options);
> {code}
> See the attached Java source file [^JCLOUDS1488.java] for the full code.
> On my system, running the attached Java code takes over 10 seconds to list a
> single file if there are 500,000 files in the container outside that prefix.
> Output from the attached code:
> {code:java}
> Number of blobs listed: 1
> First listed blob: test-container-subdirectory/file-to-list
> Time it took to list the blobs: 13256 ms
> {code}
> A more general version of this problem was reported previously in
> JCLOUDS-1371.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1483) Removing a blob from a Swift container using BlobStore.removeBlob fails.
[
https://issues.apache.org/jira/browse/JCLOUDS-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746054#comment-16746054
]
Biswa Ranjan Ray commented on JCLOUDS-1483:
---
_Trial 1:_
_b. Build failed because of testcase failure at line 117 of
testReplaceManifestUnicodeUTF8() method in StaticLargeObjectApiMockTest class._
I could able to fix the build issue but I had to set UTF8 encoding in java and
maven:
*set JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8*
*set MAVEN_OPTS=-Duser.language=en -Dfile.encoding=UTF-8*
Shouldn't it be handle by pom?
_Trial 2:_
_c. It still throws the same exception as reported earlier :_
_com.google.gson.JsonSyntaxException: java.lang.IllegalStateException:
Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $_
_This is very strange. Do you run your tests against OpenStack Swift or
another implementation?_
Putting the steps just to make sure if I'm doing right.
Step 1. I forked the project from [jclouds|https://github.com/apache/jclouds]
and cloned into my system.
Step 2. I modified
[StaticLargeObjectApi|https://github.com/apache/jclouds/blob/master/apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/features/StaticLargeObjectApi.java]
by replacing the existing code at line at 117 with
*@QueryParams(keys = \{"format", "multipart-manifest"}, values = \{"json",
"delete"})*
Step 3. Then Modified
[StaticLargeObjectApiMockTest|https://github.com/apache/jclouds/blob/master/apis/openstack-swift/src/test/java/org/jclouds/openstack/swift/v1/features/StaticLargeObjectApiMockTest.java]
by replacing the existing code at line 230 and 252 with
*assertRequest(server.takeRequest(), "DELETE",
"/v1/MossoCloudFS_5bcf396e-39dd-45ff-93a1-712b9aba90a9/myContainer/myObject?format=json=delete");*
Step 4. To ensure if my changes are taken into effect, I added a print stmt in
removeBlob() method of RegionScopedSwiftBlobStore class to print the container
name.
Step 5. Triggered a build on
[openstack-swift|https://github.com/apache/jclouds/tree/master/apis/openstack-swift]
project and added this to my project pom. Debugged and found the container
name is printed when attempted to delete a blob.
It still throws: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
Am I missing anything?
> Removing a blob from a Swift container using BlobStore.removeBlob fails.
>
>
> Key: JCLOUDS-1483
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1483
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
>Reporter: Biswa Ranjan Ray
>Priority: Major
> Labels: openstack-swift
> Attachments: BuildException.txt, NullPointerException.txt,
> StaticLargeObjectApiMockTest.html, stacktrace.txt
>
>
>
> *Usecase*: Try to delete a blob (size ~ 107kb) from a swift container using
> BlobStore.removBlob() api of jclouds.
> *Issue*: Following exception is found in console:
> com.google.gson.JsonSyntaxException: java.lang.IllegalStateException:
> *Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $*.
> *Code*: Sharing the code snippet that I've used to delete a blob from a swift
> container.
> BlobStore blobStore = getBlobStoreContext();
> blobStore.removeBlob(containerName, fileName);
> {code:java}
> //To get the BlobStoreContext for OpenStack Swift
> private BlobStoreContext getBlobStoreContext() {
> final Properties override = new Properties();
> override.put(KeystoneProperties.KEYSTONE_VERSION, "3");
> override.put(KeystoneProperties.SCOPE, "project:" +
> swiftConfig.getProject());
>
> final String credential = swiftConfig.getPassword();
> final String identity = swiftConfig.getUserDomain() + ":" +
> swiftConfig.getUsername();
> final String authUrl = swiftConfig.getAuthUrl();
>
> return ContextBuilder.newBuilder("openstack-swift")
> .endpoint(authUrl+"/v3")
> .credentials(identity,credential)
> .overrides(override)
> .buildApi(BlobStoreContext.class);
> }
> {code}
> *Debug:* Following are my observations after debugging the code.
> # The type of the blobstore is found to be RegionScopedSwiftBlobStore.
> # stepinto blobStore.*removeBlob*(containerName, fileName);
> at line 396 in *RegionScopedSwiftBlobStore* class, I
> found it expects a response from *StaticLargeObjectApi* as shown in the below
> code and this is where the exception occurs:
> **
> DeleteStaticLargeObjectResponse response =
> api.getStaticLargeObjectApi(regionId, container).delete(name);
> *Analysis*: While the api BlobStore.removeBlob fails to delete a blob in a
> Swift container, it works fine in AWS
[jira] [Issue Comment Deleted] (JCLOUDS-1483) Removing a blob from a Swift container using BlobStore.removeBlob fails.
[
https://issues.apache.org/jira/browse/JCLOUDS-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biswa Ranjan Ray updated JCLOUDS-1483:
--
Comment: was deleted
(was: I investigated and figured out the build issue I was facing in Trial 1.
Its utf8 character encoding issue. In the
StaticLargeObjectApiMockTest.testReplaceManifestUnicodeUTF8 method, the
expected and actual json doesn't match because the expected json expects a
string i.e *unic₪de* which doesn't match with the actual i.e *unic₪de*.
My OS is windows 10. Although its a trivial issue I'm trying to fix it setting
maven to UTF8.
But the actual issue w.r.t delete() method in StaticLargeObjectApi is still a
concern.)
> Removing a blob from a Swift container using BlobStore.removeBlob fails.
>
>
> Key: JCLOUDS-1483
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1483
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
>Reporter: Biswa Ranjan Ray
>Priority: Major
> Labels: openstack-swift
> Attachments: BuildException.txt, NullPointerException.txt,
> StaticLargeObjectApiMockTest.html, stacktrace.txt
>
>
>
> *Usecase*: Try to delete a blob (size ~ 107kb) from a swift container using
> BlobStore.removBlob() api of jclouds.
> *Issue*: Following exception is found in console:
> com.google.gson.JsonSyntaxException: java.lang.IllegalStateException:
> *Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $*.
> *Code*: Sharing the code snippet that I've used to delete a blob from a swift
> container.
> BlobStore blobStore = getBlobStoreContext();
> blobStore.removeBlob(containerName, fileName);
> {code:java}
> //To get the BlobStoreContext for OpenStack Swift
> private BlobStoreContext getBlobStoreContext() {
> final Properties override = new Properties();
> override.put(KeystoneProperties.KEYSTONE_VERSION, "3");
> override.put(KeystoneProperties.SCOPE, "project:" +
> swiftConfig.getProject());
>
> final String credential = swiftConfig.getPassword();
> final String identity = swiftConfig.getUserDomain() + ":" +
> swiftConfig.getUsername();
> final String authUrl = swiftConfig.getAuthUrl();
>
> return ContextBuilder.newBuilder("openstack-swift")
> .endpoint(authUrl+"/v3")
> .credentials(identity,credential)
> .overrides(override)
> .buildApi(BlobStoreContext.class);
> }
> {code}
> *Debug:* Following are my observations after debugging the code.
> # The type of the blobstore is found to be RegionScopedSwiftBlobStore.
> # stepinto blobStore.*removeBlob*(containerName, fileName);
> at line 396 in *RegionScopedSwiftBlobStore* class, I
> found it expects a response from *StaticLargeObjectApi* as shown in the below
> code and this is where the exception occurs:
> **
> DeleteStaticLargeObjectResponse response =
> api.getStaticLargeObjectApi(regionId, container).delete(name);
> *Analysis*: While the api BlobStore.removeBlob fails to delete a blob in a
> Swift container, it works fine in AWS S3 and GCS container. I also observed
> that if I use *ObjectApi.delete(objectName)* instead of
> *BlobStore.removeBlob* then the blob gets deleted from the swift container
> without any issue. As per the java doc of StaticLargeObjectApi, it is in beta
> and still under evaluation. Is this api stable?
> Any help is highly appreciated.
> Thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
