You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/06/03 05:36:59 UTC

[jira] [Commented] (JCLOUDS-912) GCS uploads with InputStream payloads are not working

    [ https://issues.apache.org/jira/browse/JCLOUDS-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15313604#comment-15313604 ] 

ASF subversion and git services commented on JCLOUDS-912:
---------------------------------------------------------

Commit f7596fbc219cd3cf32cba9cac31524ad9ca62866 in jclouds-labs-google's branch refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=f7596fb ]

JCLOUDS-912: Remove GCS simpleUpload UploadBinder

This is not necessary; jclouds binds the Payload automatically;
jclouds binds the Payload automatically.


> GCS uploads with InputStream payloads are not working
> -----------------------------------------------------
>
>                 Key: JCLOUDS-912
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-912
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-blobstore, jclouds-labs-google
>    Affects Versions: 1.9.0
>         Environment: Ubuntu 14.04.2 LTS 64-bit
> java version "1.7.0_76"
> Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
>            Reporter: Ben Piper
>            Assignee: Daniel Broudy
>              Labels: google-cloud-storage
>
> It seems that Payloads based on an InputStream are not currently working with the google-cloud-storage API, either with simpleUpload or multipartUpload.  The stream is getting closed before a single byte is read for transmission to the GCS endpoint.
> The payload in the request object is first initialised when GeneratedHttpRequest.Builder.build is called in RestAnnotationProcessor.apply, and then setPayload is later called on the HttpRequest object by MultipartUploadBinder (or UploadBinder in the case of simpleUpload), causing the originally supplied InputStream to be closed.
> The setPayload call in UploadBinder.bindToRequest seems redundant, if the payload has already been set when the request object was built.  MultipartUploadBinder.bindToRequest wraps the original payload in a MultipartForm, but the stream in the media part will still end up being closed by the setPayload call.  At face value, it doesn't seem like MapBinder.bindToRequest is an appropriate place to call setPayload unless it is legitimate to completely replace the original payload (rather than wrap it) - or at least if it has to mutate the payload property of the request object, then it needs some way of doing it that doesn't result in the originally supplied Payload being 'released'.
> The simplest way of reproducing this is probably just to add a new integration test, similar to ObjectApiLiveTest.testMultipartJpegUpload, but using a FileInputStream based Payload rather than a ByteSource one.
> Relevant portion of stack trace is below.
> {code}
> Caused by: java.io.IOException: Stream already closed
> 	at org.jvnet.mimepull.DataHead$ReadMultiStream.fetch(DataHead.java:248) ~[mimepull-1.9.3.jar:1.9.3]
> 	at org.jvnet.mimepull.DataHead$ReadMultiStream.read(DataHead.java:219) ~[mimepull-1.9.3.jar:1.9.3]
> 	at java.io.SequenceInputStream.read(SequenceInputStream.java:208) ~[na:1.7.0_76]
> 	at java.io.SequenceInputStream.read(SequenceInputStream.java:211) ~[na:1.7.0_76]
> 	at java.io.InputStream.read(InputStream.java:101) ~[na:1.7.0_76]
> 	at com.google.common.io.ByteStreams.copy(ByteStreams.java:175) ~[guava-16.0.1.jar:na]
> 	at org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:297) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:170) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:64) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:91) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117) ~[jclouds-core-1.9.0.jar:1.9.0]
> 	at com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87) ~[guava-16.0.1.jar:na]
> 	at com.sun.proxy.$Proxy120.multipartUpload(Unknown Source) ~[na:na]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)