> On 18 Feb 2016, at 17:34, Michael McMahon <michael.x.mcma...@oracle.com> > wrote: > > On 18/02/16 16:06, Paul Sandoz wrote: >>> On 18 Feb 2016, at 16:37, Michael McMahon <michael.x.mcma...@oracle.com> >>> wrote: >>> >>>> When building a request how does one set multiple values for a header? >>>> setHeaders overwrites, does one used headers(…) instead? >>>> >>> headers(String, String) >>> and headers(String ...) both accumulate headers >>> >> What headers would be included in the request for the following expressions: >> >> - setHeader(“foo”, “value1”).setHeaders(“foo”, “value2”) > > Foo: value2 >> - headers(“foo”, “value2”).headers(“foo”, “value2”) > > Foo: value2 > Foo: value2 >
Ok, that is what i thought, unless i missed it in the docs we should document that more clearly. >>>> OK, i see there is more specification in HttpResponse.BodyProcessor. I >>>> wonder how implementations correlate the unit to bytes? Is there any >>>> correlation related to an internal buffer size? Why would the requested >>>> unfulfilled demand be greater than 1? i.e. as an implementor of a body >>>> processor how am i meant to correlate the bytes i read/write to the units >>>> required to express the unfulfilled demand? >>>> >>> There is no direct correlation between units and bytes. If the window size >>> is 1, then the processor >>> is willing to accept one more call, of whatever sized ByteBuffer. >>> >>> The implementor of the processor must then decide based on how long it >>> takes to consume the >>> data whether to update the window immediately or to delay and update it >>> later. >>> >> Sorry, still don’t get why a value greater than 1 needs to be provided. If i >> pass in 1 and may get one or more calls, then why pass in 1? Why not use a >> Runnable instead? >> > > In practice, 1 seems to be the most likely use-case, but a value of N means > that N further calls to provide 1 ByteBuffer is permitted. > > It's exactly the same with the Flow API. > It does not seem quite so because there is a correlation between the publisher and subscriber in terms of elements, where N in request(N) represents the additional unfulfilled demand to process elements that are published. In your case the process implementation has no way to correlate the demand in a meaningful way. If there was a correlation to bytes then it may be more meaningful. For example flowConsumer.accept(4096) means the processor is requesting an additional unfulfilled demand of 4096 bytes, that way the processor can control the rate in terms of something it understands and it’s up to the HTTP client to respect that (i dunno if we can get down to the traffic control level of the TCP protocol in Java). I really don’t wanna block this, but this seems to require some more bake time. If you can I recommend removing it from the API until you revise with HTTP 2. If you think this would be more work than necessary, then lets just promise to revise when HTTP 2 goes in. >>>> For responses, what happens if the Consumer<Buffer> is called outside the >>>> life-cycle of the processors? >>>> >>> Actually, that is not part of the current API. For the moment, the >>> life-cycle of the ByteBuffer is >>> that it only belongs to the processor for the duration of the call, meaning >>> it would have to be >>> copied if the data isn't consumed fully during the call. >>> >> But happens if the Consumer is invoked outside of the life-cycle of the >> response, should an ISE be thrown? >> >> Same for the LongConsumer, what happens if it is invoked outside the >> life-cycle of the request or response. > > There is no Consumer<> Here is the API signature: + T onResponseBodyStart(long contentLength, + HttpHeaders responseHeaders, + LongConsumer flowController, + Consumer<ByteBuffer> bufferpool) + throws IOException; There is Consumer<ByteBuffer> as well as LongConsumer. > but for the LongConsumer, it's not specified. I would expect it just to have > no effect. > We need to document the behaviour for both consumers. Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
