I can confirm that this fixes the problem that I was seeing on My Suse Linux 10.2 also.  If you would like me to go through the formalities of opening a problem for documentation purposes, just let me know.

I think I can shed some light on why your fix fixed the problem.

I am not a designer of network protocols, but I have a lot of experience working with
them and testing them. (In other words - don't blame me!)

The default for set reusaddr is False.
This comes from the "old days".
The way I understand it is that the problem that this is trying to prevent is:

socket1 is communicating with socket2
socket1 closes
a different process opens socket1
the new process on socket1 could possibly receive 'in process' data from socket2.
That is why it prevents future process binds for a timeout period. It is assumed that
all the 'in process' data will be sent and discarded in the timeout period.

Because this is such a hassle in certain circumstances, they added the ability to
override this behavior.

So, in light of this, what you are seeing in your fix and Raghurams
observations make sense.

- Bob

-----Original Message-----
From: Charlie Groves <>
To: Raghuram Devarakonda <>
Cc: <>;;
Sent: Sat, 28 Jul 2007 2:43 am
Subject: Re: [Jython-dev] Socket bind problems on Linux.

On 7/27/07, Raghuram Devarakonda <> wrote:
> On 7/27/07, <> wrote:
> >
> > Please note the addition of script This has the added
> > line to set reuseaddr to True.
> > The same script scenario still fails in Jython on Linux, but passes in
> > Python. Sorry for forgetting this file in the previous email.
> I tested your scripts on SuSe 10 and the results are same as you got.
> Specifically, fails with "Address already in use"
> error when it should have succeeded because of SO_REUSEADDR.

I think I fixed this in r3360. I was able to reproduce the errors
from Bob's script on my Ubuntu machine and they're fixed by that

I'm a little perplexed as to how it fixes it though. The change just
fixes a bug where the client Java Socket returned from accept on a
ServerSocket would have its setReuseAddress value set to false
regardless of its initial value; now it keeps the value in the Socket.
It seems like if a ServerSocket has reuseAddress as true, its client
Sockets will have reuseAddress true as well.

For some reason, setting reuseAddress to false on that Socket from
accept causes the bind to fail in the next run of SimpleServer2 in a
completely new process. This contradicts my understanding of
SO_REUSEADDR from the javadocs for setReuseAddress. It says setting
it should affect the all bind calls after that, and nothing about
later attempts to bind on that port after the Socket has closed.
Either those docs or wrong, or I'm missing something that my change
does. In either case it'd be nice to get some verification that this
fixes it from other people that have seen the problem.

> BTW, Surprisingly, I didn't get this behaviour with my scripts and the
> only difference is that my client and server do not exchange any data.
> I don't know if that is somehow influencing next listen().

This does add a little credence to my theory. If your client and
server don't exchange data, accept would never have been called so
setReuseAddress wouldn't have been set to false incorrectly.


Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.