On Apr 17, 2008, at 5:31 AM, Gianny Damour wrote:
Hi,
It would be great to have only one TCP/IP connection opened between
an EJB client and the EJB server and this across multiple requests.
My understanding is that at the moment a TCP/IP connection is
negotiated for each EJB request which is very expensive especially
based on the rather small size of the payload being passed back and
forth over TCP/IP.
Absolutely! It's been on my mental TODO list for quite some time.
Last time I looked the trickiest thing was that the code sort of had
the notion it could close the socket, etc. If we could get a setup
similar to a servlet container where the inputstream/outputstream
passed were not the actual streams (thinking of request.getInputStream/
response.getOutputStream) it would fit really well. There might be
some code in Tomcat/Jetty that we can "borrow."
If you'd like to take a look at it, excellent!
-David
On 17/04/2008, at 12:27 PM, Kevan Miller wrote:
On Apr 16, 2008, at 6:30 PM, Trygve Hardersen wrote:
I checked out the 2.1.1 branch that is using openejb 3.0, but I'm
still getting the error. It seems less frequent though, but it's
still
bad. The stack trace is different, but the root cause is the same:
Hi Trygve,
I'm guessing that you're running on a Windows? I've only seen this
type of error happen on a Windows. Note that this is a client
socket (not a server socket). We aren't assigning the port
address... It's being assigned to the socket dynamically.
One possibility is that you are exhausting the available user port
numbers. When a socket is closed, it goes into a TIME_WAIT state
and isn't actual closed until some delay time. By default, the max
user port address is 5000 and the TIME_WAIT delay is 4 minutes. So,
it's not too difficult to exhaust all possible user port addresses.
You have to update the Windows Registry to change these values.
Here's a Windows 2000 doc on the registry settings -- http://technet.microsoft.com/en-us/library/bb726981.aspx
MaxUserPorts controls the upper range for user ports.
TcpTimedWaitDelay controls the TIME_WAIT delay.
Hopefully, increasing MaxUserPorts (e.g. 65534) and decreasing
TcpTimedWaitDelay (e.g. 30)will fix your problem.
If not, then I also recall a problem where Windows would assign the
same dynamic port address to 2 (or more) newly created sockets. It
was then a race to see which one would be activated first and the
other one would get a bind failure. Not sure there's anything we
can do about that...
--kevan
