On 01/02/2013 01:45, Scott Ferguson wrote:
> On 1/31/13 5:13 PM, Danny Coward wrote:
>> Hi Mark,
>>
>> Thanks for bringing these up, I don't think you've missed anything in
>> the spec.
>>
>> On 1/29/13 1:42 AM, Mark Thomas wrote:
>>> All,
>>>
>>>
>>>
>>>
>>
>>> 2) How is 1) affected when batching is enabled?
>>> My current thinking is that the send is completed (via the Future or
>>> SendHandler) once the message has been batched but before it has been
>>> flushed. Otherwise it would be impossible to batch multiple messages.
>> Is this the case where you are in batching mode and you call a send
>> while the container is in the middle
>> of sending the last batch. Can't the container start a new batch ?
>> Scott what do you think on this one ?
>
> I agree with Mark. (Although I think he's focusing on a slightly
> different part of the scenario than what you're describing.)
>
> As long as the send method can complete without blocking, I think the
> future/SendHandler would complete even though the data is just buffered,
> not sent.
>
> The future/SendHandler should be about avoiding blocking, not
> necessarily related to any underlying buffering.
>
> For example the following sequence:
>
> 1) RemoteEndpoint.sendStringByCompletion("hello", cb);
>
> cb completes immediately because the message fits into the container's
> buffer. The buffer is not necessarily flushed (depending on the
> container, of course.)
>
> 2) RemoteEndpoint.sendStringByCompletion("world", cb);
>
> cb can completed immediately if both messages fit in the container's
> internal buffer.
>
> (1+2 is Mark's scenario, I think. It's a bit different from your
> description because the container isn't sending anything yet.)
>
> 3) RemoteEndpoint.sendStringByCompletion("really big string that
> overflows the buffer", cb);
>
> The cb is not completed until the container has enough room after
> flushing its current buffer.
>
> (I think #3 is your scenario. I don't think the cb can be called until
> the container has flushed enough data to make room for a new sendString
> call.)
+1
Mark