A+
-- jeanfrancois
Le 2009-10-30 à 14:41, Jerome Dochez <Jerome.Dochez_at_Sun.COM> a écrit :
>
> On Oct 30, 2009, at 11:31 AM, Jeanfrancois Arcand wrote:
>
>>
>>
>> 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.
> of course but end result for the user is the same.
>>
>>> 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.c.
>
>>> 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,
> why is there http in the name ?
>
>> but we should add it explicitely under the listener for clarity if
>> we go with the System.getProperty("os.name") hack.
>
> I think we need to have a OS specific code path unfortunately.
> It would indeed be better to have this as part of the grizzly
> configuration to override the defaults but I can survive with the
> system wide property
Agree. I will first found the exact symptoms and work on it.
-- Jeanfrancois
>>
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> 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
>