Hi Jeanfrancois,
Jeanfrancois wrote:
> I like the idea. I still need to catch up on the "Strange behavior..."
> but if the above solution is implemented, would it fix Minoru issue? At
> least you discovered an issue with the BindingException (duplicated). So
> I'm all for fixing that.
Then, I will try to implement recycling the server channel once.
I am not sure whether this solution will fix Minoru issue or not, but I think that at least it may be able to help the similar case with workaround.
For fixing the issue with recycling the server channel, I think that Minoru application should be modified in order to avoid the duplicated binding situation.
i.g. Should use only one Controller.
So I also think that it is helpful for me that you catch up on the issue because I don't know how Grizzly can prevent a user from binding duplicated address completely.
After finishing the impl and testing it, I will reply for being reviewed.
Thanks!
--
Bongjae Chang
----- Original Message -----
From: "Jeanfrancois Arcand" <Jeanfrancois.Arcand_at_Sun.COM>
To: <dev_at_grizzly.dev.java.net>
Sent: Saturday, June 13, 2009 5:02 AM
Subject: Re: About recycling the server channel in XXXSelectorHandler
> Salut,
>
> Bongjae Chang wrote:
>> Hi,
>>
>> I have seen Minoru's issue("Strange behavior of Grizzly") for several days.
>>
>> Meanwhile, I thought that sometimes it was possible that a user would
>> like to use the Grizzly for both server and client.
>>
>> Of course, XXXSelectorHandler( Role.CLIENT_SERVER ) is used for both
>> server and client purpose.
>>
>> See the following use case.
>>
>> ---
>> ..
>> XXXSelectorHandler selectorHandler = new XXXSelectorHandler(
>> Role.CLIENT_SERVER );
>> selectorHandler.setPort( port );
>> selectorHandler.setInet( localAddress );
>> controller.addSelectorHandler( selectorHandler );
>> ...
>> ConnectorHandler connectorHandler = controller.acquireConnectorHandler(
>> Controller.Protocol.XXX );
>> connectorHandler.connect( remoteSocketAddress, new InetSocketAddress(
>> localAddress, port ); ---- (1)
>> connectorHandler.write(...);
>> ...
>> ---
>>
>> At above (1), the following method is called finally. (TCP is similar to
>> UDP)
>>
>> In UDPSelectorHandler.java
>> ---
>> protected void connect(SocketAddress remoteAddress, SocketAddress
>> localAddress, CallbackHandler callbackHandler) throws IOException {
>> DatagramChannel newDatagramChannel = DatagramChannel.open();
>> newDatagramChannel.socket().setReuseAddress(reuseAddress);
>> if( localAddress != null ) {
>> newDatagramChannel.socket().bind(localAddress);
>> }
>> ...
>> }
>> ---
>>
>> If user made XXXSelectorHandler with Role.CLIENT_SERVER, and user used
>> setInet( localAddress ), binding operation will be duplicated because
>> XXXSelectorHandler#initSelector() makes the server channel which binds
>> the localAddress.
>>
>> If setReuseAddress set to be false, maybe user can't use the specific
>> address for sending through Controller#acquireConnectorHandler() and
>> ConnectorHandler#connect(remote, local). But user can use only the any
>> address like "0.0.0.0" for sending.
>>
>> If setReuseAddress set to be true, default is true, maybe at least above
>> case, there is no problem.
>>
>> But if user used one more Controller locally, unexpected result could be
>> occurred according to platform(See the "Strange behavior of Grizzly"
>> issue of dev mailing).
>>
>> So I think that it is better that Grizzly can provide a client with the
>> way of being able to use server's channel which already has been created.
>>
>> How about recycling the server channel in XXXSelectorHandler#connect()
>> if it exists?
>
> I like the idea. I still need to catch up on the "Strange behavior..."
> but if the above solution is implemented, would it fix Minoru issue? At
> least you discovered an issue with the BindingException (duplicated). So
> I'm all for fixing that.
>
>>
>> Then, could any problems be occurred?
>
> I don't think. On the contrary, I think it will help.
>
> Great work!
>
> -- 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
>
>
>
>