>> Hi,
>> in order to optimize the async read/write queue implementation I
>> had to make several changes to API.
>> 1) all async queue read/write methods return Future (returned void
>> before).
>> Think it makes sense for async. operations and doesn't break any
>> existing code. So now it is possible to use returned Future object
>> to check whether operation was completed or not. And if there was
>> an exception.
>
> +1 Does it also means that doing Future.get(10,TimeUnits.SECONDS)
> will block?
Sure.
>> 2) Introduce ByteBufferCloner interface.
>> This one may brake existing code :(
>> Recently we may pass boolean "isCloneByteBuffer" value. This
>> parameter meant, that if async writer is not able to write
>> ByteBuffer directly to the channel and is planning to add it to the
>> queue - then, if isCloneByteBuffer is true, we create a clone for
>> original ByteBuffer and add cloned buffer to the async queue
>> instead of original one. If isCloneByteBuffer is false - then
>> original byte buffer was being added to the queue.
>> The main drawback of this solution is that we can not implement our
>> custom cloner code to reuse ByteBuffer pools.
>> On other hand I know implementations, which didn't use the
>> isCloneByteBuffer parameter, but created clones itself. But this is
>> also bad, because there is always a chance (and for normal loading
>> this chance is very big), that ByteBuffer will be successfully
>> written on the socket directly without adding to a queue, so all
>> cloning process becomes redundant!
>> So now, instead of passing boolean isCloneByteBuffer parameter - we
>> pass ByteBufferCloner parameter.
>> ByteBufferCloner interface looks following:
>> /**
>> * Cloner, which will be called by {_at_link AsyncQueueWriter}, when
>> ByteBuffer
>> * could not be written directly, and will be added to the queue.
>> * Cloner may create a clone of original ByteBuffer and return it to
>> the
>> * {_at_link AsyncQueueWriter} instead of original one.
>> * Using ByteBufferCloner, developer has a chance to clone a
>> ByteBuffer only in
>> * case, when it is really required.
>> *
>> * @author Alexey Stashok
>> */
>> public interface ByteBufferCloner {
>> public ByteBuffer clone(ByteBuffer originalByteBuffer);
>> }
>> The ByteBufferCloner will be called by AsyncWriteQueue only in
>> case, if original ByteBuffer could not be completely written on
>> channel directly, and will be added to a queue. So here, in
>> ByteBufferCloner, developer could add cloning logic and will be
>> sure that cloning will not be redundant.
>> What do you think?
>
> Make sense. Will you deprecate the previous behavior, throw an
> IllegalStateException or log an issue so we can refer to that when
> dounf the release? I vote for an issue.
Actually I wanted to remove old methods, cause async write queue
implementation looks very overloaded already and to add there more
methods - could be bad idea.
Also I think that old logic with boolean isCloneByteBuffer parameter
was not used widely by developers, because of the drawbacks I mentioned.
Anyway I'd like to hear if anyone is really dependent on that, if yes
- I'll probably leave old methods deprecated.
Thanks.
WBR,
Alexey.
>
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>> Will appreciate any feedback.
>> Thanks.
>> WBR,
>> Alexey.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>