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