Mailing-List: contact axis-user-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@xml.apache.org
Message-ID: <3D47E7CA.16CCFEE6@ieee.org>
Date: Wed, 31 Jul 2002 09:36:10 -0400
From: James Black <jblack@ieee.org>
MIME-Version: 1.0
To: axis-user@xml.apache.org
Subject: Re: Socket problems
References: <21B200DF0688CC45ACF38F49D227983206B9BA@buebe002.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Geza.Szocs@nokia.com wrote:

> I tried myself hacking the Call object, and closing the socket
> there. Unfortunately the problem remains the same.
> At my second attempt I only ran a test only in one direction,
> so this time teh client framework was not involved.
> I just hit the server from several threads, using Sockets (not URLConnection),
> and I closed down all sockets immediately after using them.
> Netstat showed that around 4000 (!) sockets have been active.
> This number was quickly increasing up to 4000, and then stabilized around
> this number. Even if I shut down both Tomcat and the client on the other machine,
> the sockets remain there for around one minute. After one minute the
> sockets are closed one by one by the OS. I looks to me as if this
> were an operation system characterestic. The tests were run on a
> Solaris 8. What do you think ? Does anyone knows what exactly happens to
> a socket when you invoke socket.close() ? I mean how can you instruct
> the Solaris to immediately free up network resources associated to a
> socket ?
> What I'll try to do next is to build up some kind of connection pool.

  You may want to look at the Socket class API documentation, at setSoLinger and
setNoTCPDelay.
  It sounds like the socket is lingering before closing, so you will want to turn
that off, but that also means that any data in the pipe that is unread by the client
will be lost if you close too quickly.
  A linger time of 5 seconds would seem pretty reasonable though, but people will
need to play and see what works best.