Here it is.
Thanks.
Alexey.
On Nov 25, 2008, at 19:17 , Jeanfrancois Arcand wrote:
> Salut,
>
> can you send the diff? Might help getting feedback!
>
> A+
>
> --Jeanfrancois
>
> Oleksiy Stashok wrote:
>>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
>