Salut,
Bongjae Chang wrote:
> 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.
OK great. I should be up to speed before the end of the day.
Thanks!
-- Jeanfrancois
>
> 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
>>
>>
>>
>>