On 2/26/13 6:08 AM, Mark Thomas wrote:
> On 25/02/2013 16:42, Danny Coward wrote:
>
>> 2) Check on batching semantics on RemoteEndpoint (mostly for you
>> Scott !)
>>
>> Wanted to check on the blocking and async semantics when batching is
>> enabled. The following are true:
>>
>> 1) a blocking write to the batch-buffer that does not cause the
>> batch-buffer to be sent returns as soon as the message is put in the
>> batch-buffer.
> +1
>
>> 2) a blocking write to the batch-buffer that causes the batch-buffer to
>> be sent returns as soon as the whole batch-buffer is sent on the wire.
> I think it returns:
> - after the buffer has been written to the wire
> - and after the write has been written to the (now empty buffer|wire)
>
> (the message be be written directly to the wire if it is too big for
> the buffer)
The exact flushing behavior is an implementation detail. (I'm pretty
sure I'm agreeing with Mark.)
The implementation might send just enough of the batch-buffer to free up
room
for the new write.
The only thing the application knows is that any modifiable structured
(like byte[] or ByteBuffer or encoded Object) has been copied or sent,
so it's free to reuse it.
>
>> 3) an async write to the batch-buffer that does not cause the
>> batch-buffer to be sent is gets the completed callback as soon as the
>> write to the batch-buffer completes.
> +1
>
>> 4) an async write to the batch-buffer that causes the batch-buffer to be
>> sent is gets the completed callback as soon as whole batch-buffer is
>> sent on the wire.
> Same as 2.
The application knows:
1. it can now reuse any shared byte[]/ByteBuffer/encoded Object
2. it can call another write without triggering an IllegalStateException.
Anything else is an implementation detail.
-- Scott
>
>> 4/4 ?
>
> Yes, with the clarifications above about the message that triggered
> the flush.
>
> Mark
>
>