JK,

On 11/23/21 08:23, jkla...@iki.fi wrote:
I've been tasked with the maintenance of a client's legacy Tomcat 8.0
application servers. The person who initially configured Tomcat on
them is no longer with the company, and I've basically been thrown
into the deep end with no prior Tomcat or Java knowledge. Their Java
developers are also unfamiliar with the Tomcat setup. I've been
reading through a bunch of documentation to try to make sense of it
all, so excuse my extreme newbieness.

The servers are running a single Java application under Tomcat that
connects to a MySQL server. The data sources are configured in the
META-INF/context.xml file of the Java application. It contains a
bunch of Resource elements with the javax.sql.DataSource type.

Sounds good so far.

Step 1 in everything you do should be to upgrade to a supported version of Tomcat. (And probably a recent JVM if the system has been neglected.) Either Tomcat 8.5 or 9.0 should be acceptable, though you may have *slightly* less difficulty moving to Tomcat 8.5. After migrating to Tomcat 8.5, I would immediately start testing with Tomcat 9.0.

Any JVM should work. I'd choose the most recent for your platform.

We're in the process of adopting ProxySQL in front of MySQL, to act
as the connection pooler and for separating read and write traffic to
different database instances. After this, we have no need for DBCP or
any other Java-level pooling – in fact, having two levels of
connection pooling would probably be detrimental to performance, and
certainly to our ability to diagnose issues.

ProxySQL is, mostly, a load-balancing and caching product. Sure, it can provide connection-pooling, but that doesn't mean that you want your application making 1000 simultaneous requests to the proxy.

If I were you, I'd leave the application configuration alone (except maybe for adjusting the "size" of the connection pool) and only change the connection string so it points to your ProxySQL instance(s) instead of directly to the database.

Trouble is, based on my reading of the JNDI Resources HOW-TO, the
Java EE specs require that the data source implementation features
connection pooling, and Tomcat follows this. Accordingly, the
Resource element features a bunch of pooling-related DBCP
attributes.

I haven't been able to figure out how to entirely disable DBCP so
that ProxySQL could handle the pooling entirely.

You can't. You'd have to tear-out the use of the JNDI-provided DataSource altogether which isn't worth your time.

I can leave out the pooling-related Resource attributes, but that
probably just causes a bunch of defaults to be used.
Correct.

I could maybe configure a "pool" of one connection on the Java side,
but my intuition says that's a bad idea, and I'm not sure how to do
it anyway.
Yes, this would be a terrible idea: only one thread can (well... should) use a connection at any given time. Setting the pool size to "1" would probably make your application unusable in a production setting.

What seems the most realistic
option is configuring the MySQL connection in some other, non-pooled
fashion outside Tomcat, but I don't know how. With the last option,
it would have to be something that requires minimal code changes in
the Java application.

Just leave the pooling in-place. In order to avoid stupidity, I would make thew pool-size of the DBCP-configured pool compatible with your ProxySQL pool-size. That doesn't mean x=y, necessarily. If you have N servers all connecting, I might configure the proxy and nodes like this:

  node pool size ~= proxy pool size / N

I wouldn't make it exactly pps/N because you may get uneven load-balancing of your requests, in which case you might have a single node with lots of traffic that COULD be handled by the ProxySQL server, but is being throttled (unfairly) in the individual node.

But seriously, your first order of business (way before introducing ProxySQL) should be to upgrade Tomcat and get yourself onto a safe, supported environment.

-chris

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

Reply via email to