Re: About async read, write inteface and UDPConnectorHandler's blocking write
>
>> In SSLConnectorHandler.java
>> ---
>> public Future<AsyncQueueWriteUnit> writeToAsyncQueue(Socket Address
>> dstAddress, ByteBuffer buffer, AsyncWriteCallbackHandler
>> callbackHandler, AsyncQueueDataProcessor writePreProcessor) throws
>> IOException {
>> return writeToAsyncQueue(dstAddress, buffer, callbackHandler,
>> writePreProcessor);
>> }
>> ---
>> If user calls above method, infinite loop will be occurred because
>> the method calls itself recursively.(Above method is current svn's
>> code!)
>> What do you think?
>
> huh! This is strange that nobody reported that issue, so nobody used
> it...I think it needs to call
>
>> /**
>> * {_at_inheritDoc}
>> */
>> public Future<AsyncQueueWriteUnit> writeToAsyncQueue(
>> SocketAddress dstAddress, ByteBuffer buffer,
>> AsyncWriteCallbackHandler callbackHandler,
>> AsyncQueueDataProcessor writePreProcessor, ByteBufferCloner cloner)
>> throws IOException {
>> isAsyncWriteQueueMode = true;
>> return selectorHandler.getAsyncQueueWriter().write(
>>
>> underlyingChannel.keyFor(selectorHandler.getSelector()), dstAddress,
>> buffer, callbackHandler, writePreProcessor, cloner);
>> }
>
> with a null for ByteBufferCloner...Alexey?
Yep, good catch :)
WBR,
Alexey.
>
>
> Thanks!
>
> -- Jeanfrancois
>
>> Please advice me if I am misunderstandind them.
>> Thanks.
>> --
>> Bongjae Chang
>> ----- Original Message ----- From: "Jeanfrancois Arcand" <Jeanfrancois.Arcand_at_Sun.COM
>> >
>> To: <dev_at_grizzly.dev.java.net>
>> Sent: Thursday, May 14, 2009 11:15 PM
>> Subject: Re: About async read, write inteface and
>> UDPConnectorHandler's blocking write
>>> Salut,
>>>
>>> Bongjae Chang wrote:
>>>> Hi,
>>>> I have several proposals and questions.
>>>> (1)
>>>> CacheableConnector doesn't implement AsyncQueueWritable and
>>>> AsyncQueueReadable interface.
>>>> I think that it is not difficult that CacheableConnector
>>>> implements AsyncQueueWritable and AsyncQueueReadable interfaces.
>>>> What do you think?
>>> +1
>>>
>>>> (2)
>>>> XXXConnectorHandler already implements AsyncQueueWritable and
>>>> AsyncQueueReadable interfaces except for CacheableConnector, so
>>>> how about moving two interfaces to ConnectorHandler interface
>>>> like this?
>>>> ----
>>>> public interface ConnectorHandler extends Handler, Closeable,
>>>> *AsyncQueueWritable, AsyncQueueReadable* {
>>>> ...
>>>> }
>>>> ----
>>>> Then, does ConnectorHandler owe too many duties?
>>> My goal when I created the ConnectorHandler interface was to let
>>> people
>>> implement their own...after more than 2 years, I've never see
>>> someone
>>> using that interface directly. This is one of the reason why such
>>> low
>>> level API got dropped in 2.0. So +1 for your proposal. I don't
>>> think it
>>> add too many duties.
>>>
>>>
>>>> (3)
>>>> UDPConnectorHandler doesn't support a blocking write like this.
>>>> ----
>>>> public long write(ByteBuffer byteBuffer, boolean blocking) throws
>>>> IOException {
>>>> ...
>>>> if( blocking) {
>>>> *throw new IllegalStateException("Blocking mode not
>>>> supported");*
>>>> } else {
>>>> ...
>>>> }
>>>> }
>>>> ----
>>>> I am curious to know the reason.
>>> I think we just never had a chance to fully implement and test it.
>>> If
>>> you look in OutputWriter, we added support for blocking but we never
>>> finished it. So I would be interested to get you proposal on that.
>>>
>>> Thanks!!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>> Please advice me.
>>>> Thanks.
>>>> --
>>>> Bongjae Chang
>>> ---------------------------------------------------------------------
>>> 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
>