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.
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.
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?
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
>
>
>
>