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

Andrew Gaul commented on JCLOUDS-639:
-------------------------------------

You can hack this in with a InputStream payload with a CountingInputStream 
wrapper.  Note that InputStream payloads disable retries on network errors, but 
I belileve that this is the best you can do with jclouds as-is.  jclouds really 
needs proper async support for these long running tasks, since transferring 
large multi-part blobs can take hours or days.

> Provide methods to get the progress of a running upload to a blobstore
> ----------------------------------------------------------------------
>
>                 Key: JCLOUDS-639
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-639
>             Project: jclouds
>          Issue Type: Improvement
>          Components: jclouds-blobstore
>    Affects Versions: 1.7.3
>         Environment: doesn't matter
>            Reporter: Peter
>
> The jclouds library should provide a way to get progress information about a 
> running upload to any blobstore (information like how many bytes where 
> already transferred and optionally average speed of the transfer).
> In _JavaUrlHttpCommandExecutorService_, the outputStream is already being 
> wrapped in a _CountingOutputStream_, but there is no way to call the 
> _getCount()_ method from outside the method. 
> There should be some way to access the current count of bytes already sent to 
> calculate the status of the upload. Additionally a way to get the average 
> speed would be nice, but I guess this is more optional because you can 
> calculate the speed on your own if you know how many bytes where already 
> transferred.
> Another option to solve this, is to provide access to provider-specific 
> features like the ProgressListener in the S3-API (see 
> http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/ProgressListener.html),
>  but I guess that not all vendors have something similar in their APIs, 
> anyway the first approach would be a more generic one. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to