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.
> Geza -
> I got poked into posting a patch (
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11296 ). I
> had time to
> write one but not to test it, sorry, and in any case it
> sounds like your
> in a better position to stress test the client code than I am?
Well, switching to CommonsHTTPSender is not an easy job for me, because
my server works with an already hacked HTTPSender, which includes
some brand new features. Today it is sure that I won't have the time to
test your client, but I'll do my best. G.
|
