Eric,
On 12/29/21 19:23, Eric Robinson wrote:
-----Original Message-----
From: Mark Eggers <its_toas...@yahoo.com.INVALID>
Sent: Wednesday, December 29, 2021 6:18 PM
To: users@tomcat.apache.org
Subject: Re: Do I Need Network NameSpaces to Solve This
Tomcat+Connector/J Problem?
Eric:
On 12/29/2021 1:04 PM, Eric Robinson wrote:
We want to run a large number of tomcat instances on the same server
without virtualization or containerization. Each instance is executed from its
own folder tree and listens on its own unique TCP port. Each instance will run
code that connects to a backend database server to send queries that are
triggered by JSP calls from users. We've done this successfully with up to 120
instances of tomcat running on the same server while avoiding the overhead
of virtualization and the complexity of containers. Based on our experience
over the past decade, we know that we could potentially host 500 or more
separate tomcat instances on the same server without running into
performance problems. So now we want to make it 500 parallel instances.
Here's the problem. When tomcat initiates an outbound connection (for
example, with Connector/J to query a backend database) it establishes a
socket, and the socket has a client port. With thousands of users making
requests that require the tomcat services to query back end databases, the
OS can easily run out of available client ports to allocate to sockets. To avoid
that problem, we can assign multiple IPs to the server and use the
localSocketAddress property of Connector/J to group tomcats such that only
a subset of them each use the same source IP. Then each group will have its
own range of 64,000-ish client ports. I've tested this and it works.
My question is, is there a better way?
Are you using database connection pooling? If you are, wouldn't the
outbound connections to the database from a particular Tomcat be limited to
the maxTotal in your context.xml (maxActive in Tomcat 7).
So unless you're using a huge pool, wouldn't the required number of
outbound ports be fairly small?
. . . just my two cents
/mde/
Unfortunately, we are under vendor constraints. They apparently have an issue
with connection pooling.
Not pooling connections will very likely negatively affect performance.
When you say "they ... have an issue with connection pooling" do you
mean that they have a technical problem, or do you mean that there is
some ill-conceived policy against them?
Oh, maybe they are paranoid about cross-client leakage between
connections. Well, if the application can't be trusted not to leak that
kind of info, then it can't be trusted to make the connections properly
in the first place.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
