Salut,
Bongjae Chang wrote:
> Hi,
>
> About (1) and (2), I filed the issue #608 and attached the proposed patch.
>
> About (3), I am writing a patch. But I could find that some points could be improved more.
>
> Now, XXXConnectorHandlers have read(...), write(...), async read and async write API separately.
>
> It seem that most of I/O methods are similar, so I think that it is better that common I/O operations are moved to AbstractConnectorHandler.
>
> Then I think that "(3) UDPConnectorHandler doesn't support a blocking write" issue could be fixed easily because write(...) API could be shared between TCPConnectorHandler and UDPConnectorHandler.
>
> Here is sample.
>
> In AbstractConnectorHandler.java
> ---
> public long write(ByteBuffer byteBuffer, boolean blocking) throws IOException {
> ...
> if(blocking) {
> return OutputWriter.flushChannel(underlyingChannel, byteBuffer);
> } else {
> ...
> try {
> while(...) {
> // casting not DatagramChannel in UDP or SocketChannel in TCP but WritableByteChannel in both UDP and TCP.
> nWrite = ((WritableByteChannel)underlyingChannel).write(byteBuffer);
> ...
> }
> }
> ...
> }
> }
> ---
>
> Of course, maybe some protocols should override the method for specific setting.
Agree. But I like moving that core like you propose.
>
> And read(...) method is similar to above write(...) method.(I think that we can use ReadableByteChannel's casting).
>
> In addition, async read and write methods could be simplified, too. Then we can also reduce any mistakes in specific ConnectorHandler like this.
Agree.
>
> 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?
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
>>
>>
>>
>>