Hi,
I wrote the proposed patch about this issue experimentally.
In UDP, the patch is simple because it overrides some TCPSelectorHandler's methods.
But in TCP, if only accepted socket channel existed and the socket's remote address was equal to each other(ConnectorHandler's remote address), I recycled it.
I used a Map and a List for caching accepted socket channels and client socket channels which ConnectorHandler used for connecting in TCPSelectorHandler.
But frankly speaking, I didn't like it completely and I didn't find any better ideas in TCP.
Once, I attached the patch and a simple unit test case.
When I tested it, it worked well and all unit tests passed locally.
But I think that more tests needed and it should be reviewed carefully because any regressions which I have not thought could exist.
I look forward to your feedback or any ideas.
Thanks!
--
Bongjae Chang
----- Original Message -----
From: "Bongjae Chang" <carryel_at_korea.com>
To: <dev_at_grizzly.dev.java.net>
Sent: Saturday, June 13, 2009 5:26 PM
Subject: Re: About recycling the server channel in XXXSelectorHandler
> 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
>>
>>
>>
>>