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