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
>