Jerome Dochez wrote:
>
> On Oct 30, 2009, at 11:17 AM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Jerome Dochez wrote:
>>> Jean Francois, I think we have a problem...
>>> I remember this created an enormous amount of pain in the past.
>>
>> Yes it will most probably.
>>
>>> There is something I don't quite understand, please clarify :
>>> - you allow to bind to an existing port.
>>> - on windows, if he port is used by tomcat
>>
>> ..if the port is occupied (not only a Java program)
>>
>> , you say nothing which seems
>>> consistent with the above statement
>>
>> Indeed. On win32 we bind event if the port is currently in use (hence
>> the issue).
>>
>>> - on unixes, you fail with SEVERE: doSelect IOException
>>
>> Yes, the JDK fail to bind.
>>
>>> java.net.BindException: Address already in use:
>>> why do you fail on unix if you allow to bind to an existing port ?
>>
>> The JDK fail => Grizzly cannot control that part. In short, Win32
>> allow you to blindly bind, where Unix don't, always checking the
>> socket state whatever the state is. Win32 seems to allow you to bing
>> on "temporary state".
>>
>>> can you also clarify also what is the messy part of doing something
>>> special for win32.
>>
>> I can grab the OS via System.getProperty("os.name") and only turn of
>> reuseAddress for win32. But that's messy as GF will not re-act the
>> same based on the OS.
> why would it be different in behavior ?
Well OS/technically this is different.
>
> we would fail on both platform, on Windows because of your check, on
> Unixes because the JDK binding will fail.
>
> I am pretty sure that Solaris allows for multiple bindings to the same
> port, in order to do multiplexing, which might be what windows authorize
> too, no ?
I don't think that's the same feature as the JDK team would have not
implemented this "strange" behavior, e.g reuse=true produces
BindException on Unix, but not in Win32.
> I am wondering, should we make this setReuseAddress() a configurable
> element, otherwise how can people leverage the underlying platform
> features ?
This is already configurable using com.sun.grizzly.http.reuseAddress,
but we should add it explicitely under the listener for clarity if we go
with the System.getProperty("os.name") hack.
A+
-- Jeanfrancois
>
> jerome
>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>> thanks, jerome
>>> On Oct 30, 2009, at 10:45 AM, Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> in order to fix Issue 10690 for win32 users:
>>>>
>>>> * http://is.gd/4Il5u
>>>>
>>>> I've turned off the java.net.Socket.setReuseAddress()
>>>>
>>>> * http://is.gd/4Ilnw
>>>>
>>>> for all TCP listeners (8181,4848,8080,3700,7676) independent of the
>>>> OS (will be a little messy if I do it only for win32)
>>>>
>>>> The effect you will notice once 1.9.18-f gets integrated is doing:
>>>>
>>>> java -jar glassfish.jar
>>>> CTRL-C
>>>> java -jar glassfish.jar
>>>>
>>>> will produce a BindException and GF will not start. The reason is
>>>> the underlying OS may takes some times to release a TCP port, and
>>>> since we no longer allow binding on an existing port, it can/will
>>>> produce that exception.
>>>>
>>>> Unfortunately, it may breaks some existing tests who stop/start
>>>> listeners too fast.
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>