[FYI] More frequent BindException to occur

[Jeanfrancois Arcand-2]

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@...
For additional commands, e-mail: dev-help@...

[Jerome Dochez]

Jean Francois, 

I think we have a problem...

I remember this created an enormous amount of pain in the past.

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, you say nothing which seems consistent with the above statement

- on unixes, you fail with SEVERE: doSelect IOException

java.net.BindException: Address already in use:

why  do you fail on unix if you allow to bind to an existing port ?

can you also clarify also what is the messy part of doing something special for win32.

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@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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.

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@...
>> <mailto:dev-unsubscribe@...>
>> For additional commands, e-mail: dev-help@...
>> <mailto:dev-help@...>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jerome Dochez]

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 ?

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 am wondering, should we make this setReuseAddress() a configurable  
element, otherwise how can people leverage the underlying platform  
features ?

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@... <mailto:dev-unsubscribe@...
>>> >
>>> For additional commands, e-mail: dev-help@... <mailto:dev-help@...
>>> >
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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@...
>>>> <mailto:dev-unsubscribe@...>
>>>> For additional commands, e-mail: dev-help@...
>>>> <mailto:dev-help@...>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bill Shannon]

This issue came up a week or two ago in a bug report.
I looked into it enough to determine that it's incredibly
ugly and Windows is just broken.

As I remember...

After closing a socket, the socket can be left in a "timed wait"
state for some time after the program has exited.  Unless you use
the "reuse address" flag, a program can't bind to the socket even
though no other program is using the socket.

On Unix, "reuse address" allows you to bind to sockets that are in
this state.  It doesn't allow you to bind to sockets that are
actively open and in use by another program.

On Windows, "reuse address" allows you to bind to the socket even
though another program is actively using the socket.

I never figured out if there was a way to get the Unix behavior on
Windows.  There might be at the C level, but probably not at the
Java level.

Not using "reuse address" on Windows means that in some cases
(server crash?  server restart?) you won't be able to bind to the
socket you need.

At least, that's my understanding.  Hopefully someone with deeper
understanding of this issue can tell us what to do...

Maybe someone should consult with one of the JDK networking experts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jerome Dochez]

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.

>
>
> 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@... <mailto:dev-unsubscribe@...
>>>>> >
>>>>> For additional commands, e-mail: dev-help@...  
>>>>> <mailto:dev-help@...>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Le 2009-10-30 à 14:39, Bill Shannon <Bill.Shannon@...> a écrit :

> This issue came up a week or two ago in a bug report.
> I looked into it enough to determine that it's incredibly
> ugly and Windows is just broken.
>
> As I remember...
>
> After closing a socket, the socket can be left in a "timed wait"
> state for some time after the program has exited.  Unless you use
> the "reuse address" flag, a program can't bind to the socket even
> though no other program is using the socket.
>
> On Unix, "reuse address" allows you to bind to sockets that are in
> this state.  It doesn't allow you to bind to sockets that are
> actively open and in use by another program.
>
> On Windows, "reuse address" allows you to bind to the socket even
> though another program is actively using the socket.
>
> I never figured out if there was a way to get the Unix behavior on
> Windows.  There might be at the C level, but probably not at the
> Java level.
>
> Not using "reuse address" on Windows means that in some cases
> (server crash?  server restart?) you won't be able to bind to the
> socket you need.
>
> At least, that's my understanding.  Hopefully someone with deeper
> understanding of this issue can tell us what to do...
>
> Maybe someone should consult with one of the JDK networking experts

Working with the nio team on it.

-- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Le 2009-10-30 à 14:41, Jerome Dochez <Jerome.Dochez@...> 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.
>>
>>
>> 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@... <mailto:dev-unsubscribe@...
>>>>>> >
>>>>>> For additional commands, e-mail: dev-
>>>>>> help@... <mailto:dev-help@...
>>>>>> >
>>>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

A+
-- jeanfrancois

Le 2009-10-30 à 14:41, Jerome Dochez <Jerome.Dochez@...> 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@... <mailto:dev-unsubscribe@...
>>>>>> >
>>>>>> For additional commands, e-mail: dev-
>>>>>> help@... <mailto:dev-help@...
>>>>>> >
>>>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...