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.)
-- Scott