geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: remote ejb scalability issue
Date Thu, 17 Apr 2008 12:31:10 GMT

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.


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:// 
> 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

View raw message