Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <658860F1FF3F65478C90C5DF81CB7858207F33@kang.na.wrq.com>
From: Bhushan Khanal <bhushank@wrq.com>
To: "'axis-dev@ws.apache.org'" <axis-dev@ws.apache.org>
Subject: RE: sockets lingering in unit tests on some platforms
Date: Wed, 9 Jul 2003 14:35:40 -0700 
MIME-Version: 1.0
Content-Type: text/plain

You may also be able to work around the problem by running the clients on a
different machine than the server. If my memory serves me right, I think
it's just the client (the one who calls disconnect first) sockets that are
in a TIME_WAIT state.

Good luck.
Bhushan

-----Original Message-----
From: Eric.D.Friedman@wellsfargo.com [mailto:Eric.D.Friedman@wellsfargo.com]

Sent: Wednesday, July 09, 2003 11:33 AM
To: axis-dev@ws.apache.org
Subject: RE: sockets lingering in unit tests on some platforms


Thanks guys, I'll try it tonight and let you know how I fare.

Eric

-----Original Message-----
From: Tom Jordahl [mailto:tomj@macromedia.com]
Sent: Wednesday, July 09, 2003 11:28 AM
To: 'axis-dev@ws.apache.org'
Subject: RE: sockets lingering in unit tests on some platforms


+1 to trying REUSEADDR.  I have run in to this kind of thing before (in C
apps) too.

+1 to adding that to the Axis Java code if it helps.


--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Bhushan Khanal [mailto:bhushank@wrq.com] 
Sent: Wednesday, July 09, 2003 1:02 PM
To: 'axis-dev@ws.apache.org'
Subject: RE: sockets lingering in unit tests on some platforms

Eric, 

You may be running into a problem commonly seen with C/C++ based servers
where the server sockets are in TIME_WAIT state. The sockets remains in that
state for the duration your Maximum Segment Lifetime (MSL varies from OS to
OS but I think its between 30 sec to 2 min). As you noticed, you will not be
able to bind or listen on that socket until its clears that state. BTW you
can check the socket state using netstat.

One way to get around this problem is by setting SO_REUSEADDR socket option
before you bind. I must say that I have not tried setting that option via
1.4 Java sockets. A lot of socket options were no-ops with 1.3 and earlier
VM's so you will have to try it out to see for sure.

Bhushan Khanal


-----Original Message-----
From: Eric.D.Friedman@wellsfargo.com [mailto:Eric.D.Friedman@wellsfargo.com]

Sent: Wednesday, July 09, 2003 9:23 AM
To: axis-dev@ws.apache.org
Subject: sockets lingering in unit tests on some platforms


I've noticed, when running the all-tests target on OS X with java 1.4.1,
that the sockets acquired (and supposedly released) for the purposes of
running the test.wsdl.multithread test case remains bound for a period of
time after the test is complete.  This causes the test suite to fail if you
run it again.

I spent some time hacking around with this last night and confess to being
stumped.  Here's what I've learned:

* It's definitely repeatable on OS X, but not always;
* It's seriously annoying;
* The problem occurs when the *client* tries to connect to the port in
question.  I added some debugging hooks and found that in some cases the
server code (SimpleAxisServer) was unable to bind to the socket.
* FWIW, I wrote some perl code to bind to the same socket and can reproduce
the problem there too -- the java process for the server is dead and gone,
but the socket's not released for a while after.
* I tried putting finalizers and try {} finally { /* really close everything
*/ } hooks in place, but no dice.
* You can't connect to the socket in question, but you also can't bind() it,
at least not always.

A log of the failed test is attached.  I'd appreciate knowing if anyone has
the same issue and would be grateful if someone with access to an OS X
machine could attempt to reproduce the problem.  You don't have to run all
of the tests -- just build axis from source and then execute "ant run" from
test/wsdl/multithread a few times in rapid succession - i.e ant run && ant
run && ant run or some such.

Thanks,
Eric

 <<run.log.txt>>