Mark,

> > My question is, is there a better way?
>
> I can only think of variations on a theme.
>
> The ~64k limit assumes client IP, server IP and server port remain constant.
> i.e. just client port is varying.
>
> That suggests there is a single IP for the database server and that it is
> listening on a single port.
>
> You are currently varying client IP. Varying server IP is unlikely to be any
> different in terms of ease of management etc.
>
> There may be more mileage in getting the database server to listen on more
> than one port. It depends how the database sever is structured. If it can have
> multiple listeners all passing connections to the same database instance then
> adding db listeners might be a simpler way to manage this.
>
> Mark

In reality, there are multiple database servers. Even so, we have seen cases 
where the vendor software consumed huge numbers of TCP connections rapidly due 
to some function of the java code, and started throwing errors about not being 
able to open sockets. We alleviated the issue by increasing the number of 
available client ports, but there were less than 100 tomcat instances on the 
app server. When we increase the count to 500, the problem will reappear unless 
we can figure out a way to distribute client port usage. That's why I came up 
with the idea of using multiple source IPs on the app server. I am new to 
network namespaces, and thought that might be a better solution, but I have no 
experience with it.

-Eric


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to