Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Blob: CreateBlobPages parameters inconsistent #117

Closed
joostdenijs opened this issue Jul 16, 2012 · 1 comment
Closed

Blob: CreateBlobPages parameters inconsistent #117

joostdenijs opened this issue Jul 16, 2012 · 1 comment
Milestone
Backlog

Comments

@joostdenijs
Copy link
Contributor

Dev estimate: 8
Test estimate: 5

Moved from the private repository.

CreateBlobPages takes "length" and "contentStream", which seems redundant. I interpreted it like this:

  1. The consumer has a random stream, and wants to write out only "lengh" part of it.

However, the entire stream is written out. What's worse, the length is used to construct the SharedKey signature, so the server rejects the packet with a 409.

I'd suggest that we do one of the following:

  1. Get rid of the "length" parameter, and calcualte the length from the stream itself (like is done in CreateBlockBlob).
  2. Clamp the stream that is passed to Jersey to only take "length" parts of the stream.
    I prefer Blob storage hangs for files > about 3500 kb #1 for consistance and ease of use.

The documentation is wrong, is echos what I initially thought the behavior should be:

  • @param length
  •        The number of bytes to read from the <em>contentStream</em> parameter into the specified range.
    I believe that the reason of having the length is for parity with the underlying REST API.

After discuss with the team, here is what we will do
Make the length parameter optional. If length is provided, we will only use the specified part of the stream. If not, we will use the entire stream. If the customer needs to optimize for performance, he/she can pass in the length parameter as well.
gcheng pushed a commit to gcheng/azure-sdk-for-java that referenced this issue May 17, 2013
Merge pull request Azure#117 from gcheng/jsrreview
2c21739 
remove message count details and forward to for JSR review.
@gcheng
Copy link

gcheng commented Jun 24, 2014

no longer in scope

@gcheng gcheng closed this as completed Jun 24, 2014
g2vinay pushed a commit to g2vinay/azure-sdk-for-java that referenced this issue Mar 4, 2019
@mirobers
Merge pull request Azure#117 from jofriedm-msft/master
8bc11d5 
Azure Storage Client Library 4.4.0 Release
sima-zhu pushed a commit to sima-zhu/azure-sdk-for-java that referenced this issue Mar 21, 2019
@jianghaolu
Merge pull request Azure#117 from jianghaolu/master
275b3d1 
Move graph related code to fluent core
mssfang pushed a commit to mssfang/azure-sdk-for-java that referenced this issue Apr 23, 2019
@yvgopal
Fixing a minor nullref exception (Azure#117)
0655067 
* Minor nullref exception fix.

* Minor nullref exception fix.
g2vinay pushed a commit to g2vinay/azure-sdk-for-java that referenced this issue May 30, 2019
@David-Noble-at-work
Add load-balanced channel support to RntbdTransportClient (Azure#117)
4bd613b 
* WIP (Work In Progress) Merged internal direct implementation to open source branch

* Added localhost to test configurations

* Safe Deleting collection after test case is done

* Trying smaller set of collections

* Reverting it back to normal

* Merging latest develop branch from internal code base

* Merge RNTBD work-in-progress from internal repository

* Fixed some request timer issues

* Fixed some request timer issues

* Fixed some request timer issues

* FakeEndpoint is now RntbdRequestTimer-capable

* Added a blank line and confirmed that all unit tests pass

* Renamed RntbdTransportClient.Options.maxChannels as RntbdTransportClient.Options.maxChannelsPerEndpoint and reduced its default from from 65535 to 10. Impact: Improved reliability and performance.

* Renamed RntbdRequestManager.PendingRequest as RntbdRequestRecord and improved error handling in RntbdRequestManager.write to ensure correct retry behavior in the layer above RntbdTransportClient.

* RntbdRequestRecord is now a CompletableFuture<StoreResponse>. RntbdServiceEndpoint instances now write RntbdRequestRecord instances. The result: improved encapsulation and code readability.

* Code tweaks for correctness

* Refactored RntbdTransportClient.Options for improved usability.

* Refactored for improved diagnstics, testability, and usability.

* Improved request timeout error message

* Marked some classes as final

* Improved metrics and logger.debug messages. Also: confirmed direct and simple (fast), and unit tests pass locally

* Added and updated dependencies (benchmark and direct-impl) on metrics

* Corrected merge issues

* Improved RntbdMetrics and corrected some deficiencies in RntbdClientChannelPool

* Improved RntbdMetrics and corrected some deficiencies in RntbdClientChannelPool

* We now report illegal state instead of throwing an illegal state exception in two cases which may be at the root of a failure related to Read/WriteTimeoutExceptions

* Corrected an error message

* Corrected an error message

* Addressed some error recovery/reporting issues

* Added RntbdTransportClient specification

* Tweaked error handling and removed some dead code

* Tweaked error handling and removed some dead code

* Tweaked error handling and removed some dead code

* Tweaked error handling

* Tidied top-level pom.xml
navalev pushed a commit to navalev/azure-sdk-for-java that referenced this issue Dec 24, 2019
@eladiw
adding service-readme, modified service pom.xml file and updated gene…
a26d33e 
…ration script (Azure#117)
@github-actions github-actions bot locked and limited conversation to collaborators Apr 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
2 participants
@joostdenijs @gcheng