You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "jklaiho@iki.fi" <jk...@iki.fi> on 2021/11/23 13:23:50 UTC
Handling database connection pooling outside Java, without DBCP et al?
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.
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.
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. I can leave out the pooling-related Resource attributes, but that probably just causes a bunch of defaults to be used. 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. 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.
Any guidance would be appreciated.
- JK
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by Mark Thomas <ma...@apache.org>.
On 23/11/2021 13:34, Olaf Kock wrote:
> I don't have experience with this particular setup, but one sentence (in
> fact, one word) caught my attention:
>
> On 23.11.21 14:23, jklaiho@iki.fi wrote:
>> 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.
>
> The keyword here is "probably": I'd say: Finish your migration with all
> the current setup, and check if performance is worse than you expect (or
> can live with) (and if diagnosis is hindered).
>
> Then, if you /still/ want to eliminate Java pooling: The connection
> pooling interfaces aren't that big - I'm not aware of a
> non-pooling-connection-pool (or a configuration that disables what the
> pool has been written for in the first place), but implementing your own
> non-pooling-connection-pool should not be that much work, as you're only
> handing out new connections unconditionally, and close them when the app
> asks you to close them. And then configure Tomcat to use your
> implementation instead of DBCP.
No need for this.
DBCP looks exactly like a database driver to the application. So, rather
than configuring DBCP as a wrapper for the database driver, you just
configure the database driver directly.
The short version is:
- remove the pooling configuration from the resource definition
- change / set the factory attribute the the correct value for your
driver (probably com.mysql.cj.jdbc.MysqlDataSourceFactory)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by Olaf Kock <to...@olafkock.de>.
I don't have experience with this particular setup, but one sentence (in
fact, one word) caught my attention:
On 23.11.21 14:23, jklaiho@iki.fi wrote:
> 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.
The keyword here is "probably": I'd say: Finish your migration with all
the current setup, and check if performance is worse than you expect (or
can live with) (and if diagnosis is hindered).
Then, if you /still/ want to eliminate Java pooling: The connection
pooling interfaces aren't that big - I'm not aware of a
non-pooling-connection-pool (or a configuration that disables what the
pool has been written for in the first place), but implementing your own
non-pooling-connection-pool should not be that much work, as you're only
handing out new connections unconditionally, and close them when the app
asks you to close them. And then configure Tomcat to use your
implementation instead of DBCP.
(As of my assumptions about configuration options or available
implementations: I can easily be proven wrong with a link to one of them)
Also, in the beginning you mention Tomcat 8.0 - while you're at it, you
might want to upgrade to one of the versions that still get updates,
e.g. 8.5 or 9.0.
Olaf
Re: [OT] Handling database connection pooling outside Java, without DBCP et al?
Posted by Mark Thomas <ma...@apache.org>.
On 23/11/2021 13:51, Richardson, Diane wrote:
> I get the emails but how can I send an email for assistance?
Please don't hijack threads.
See http://tomcat.apache.org/lists.html#taglibs-user
Specifically, "Posting questions to the list"
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Handling database connection pooling outside Java, without DBCP et al?
Posted by "Richardson, Diane" <di...@accenture.com.INVALID>.
I get the emails but how can I send an email for assistance?
________________________________
From: jklaiho@iki.fi <jk...@iki.fi>
Sent: Tuesday, November 23, 2021 8:23:50 AM
To: users@tomcat.apache.org <us...@tomcat.apache.org>
Subject: [External] Handling database connection pooling outside Java, without DBCP et al?
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
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.
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.
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. I can leave out the pooling-related Resource attributes, but that probably just causes a bunch of defaults to be used. 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. 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.
Any guidance would be appreciated.
- JK
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________
www.accenture.com
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
JK,
On 11/25/21 04:23, jklaiho@iki.fi wrote:
>
>> On Wednesday, Nov 24, 2021 at 7:37 PM, Christopher Schultz <chris@christopherschultz.net (mailto:chris@christopherschultz.net)> wrote:
>> (on the significance of DBCP overall)
>> It's essentially "failing faster" or, IMO, "failing safer."
>
> All right, I think I see it now. A very good explanation, thank you.
>> If I were you, I'd examine the reason behind your decision to use
>> ProxySQL in the first place. Maybe it makes sense to use it, but maybe
>> it makes sense to use what you already have, and not introduce a new
>> component into the mix.
>
> I just realized that an earlier reply of mine to Olaf Kock bounced
> for some reason and never made it to the list; it had the reasoning
> behind this. Here it is again:
>
> Reason number 1: the read-write split.
>
> The MySQL database has a LOT of legacy baggage in the form of ancient
> MyISAM tables, which are really prone to table-level locks.
> (Upgrading the tables to InnoDB to enable row-level locking is a
> long-term goal, but it has been tried before unsuccessfully, so it'll
> take much more time to do it right.) We're seeing these locks and
> resulting expensive outages with certain patterns of simultaneous
> read/write loads. We've created a replica server to which we'll be
> able to point nearly all of the read traffic, which should basically
> instantly solve this problem.
This won't work with writes + reads that are in the same transaction. If
you know it's safe to issue a read separately from a write, you can use
a separate connection (pool) which queries a read-only replica. Is the
proxy smart enough to know when it's okay to issue a read to a replica
instead of a primary?
> Reason number 2: better query statistics and the capability to act
> on them without downtime
>
> At this point you'll likely not be surprised to hear that the Java
> application produces practically no useful log output. ProxySQL will
> help us to identify query-level bottlenecks, and in some cases we'll be
> able to use its other functionalities (e.g. query caching or query
> rewriting, and the ability to activate them on the fly) to work around
> problematic queries without having to touch Java code at all.
The slow query log and audit plug-in can do this as well. I'm not saying
the proxy isn't helpful for this purpose, just that other tools do exist
without introducing a new moving part in a production deployment.
> In both cases, the Java application is "the right place" to fix these
> issues (although the read-write split is a good idea for our
> environment in any case). But as complicated as the ProxySQL
> undertaking is, fixing the decades-old, poorly architected,
> monolithic legacy Java application with library versions EOL'd over a
> decade ago and tons of SQL queries that rely on old MySQL misfeatures
> would be far more time-consuming and sometimes difficult enough to
> the point of infeasibility.
Understood. Technical dept is a real thing. You do ultimately have to
pay it off, because it grows all the time.
> Anyhow, thank you for your answers. They have been extremely helpful
> and will give us confidence to move forward without worrying too much
> about the two pools coexisting.
I hope everything goes well for you.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by "jklaiho@iki.fi" <jk...@iki.fi>.
> On Wednesday, Nov 24, 2021 at 7:37 PM, Christopher Schultz <chris@christopherschultz.net (mailto:chris@christopherschultz.net)> wrote:
> (on the significance of DBCP overall)
> It's essentially "failing faster" or, IMO, "failing safer."
All right, I think I see it now. A very good explanation, thank you.
> If I were you, I'd examine the reason behind your decision to use
> ProxySQL in the first place. Maybe it makes sense to use it, but maybe
> it makes sense to use what you already have, and not introduce a new
> component into the mix.
I just realized that an earlier reply of mine to Olaf Kock bounced for some reason and never made it to the list; it had the reasoning behind this. Here it is again:
Reason number 1: the read-write split.
The MySQL database has a LOT of legacy baggage in the form of ancient MyISAM tables, which are really prone to table-level locks. (Upgrading the tables to InnoDB to enable row-level locking is a long-term goal, but it has been tried before unsuccessfully, so it'll take much more time to do it right.) We're seeing these locks and resulting expensive outages with certain patterns of simultaneous read/write loads. We've created a replica server to which we'll be able to point nearly all of the read traffic, which should basically instantly solve this problem.
Reason number 2: better query statistics and the capability to act on them without downtime
At this point you'll likely not be surprised to hear that the Java application produces practically no useful log output. ProxySQL will help us to identify query-level bottlenecks, and in some cases we'll be able to use its other functionalities (e.g. query caching or query rewriting, and the ability to activate them on the fly) to work around problematic queries without having to touch Java code at all.
In both cases, the Java application is "the right place" to fix these issues (although the read-write split is a good idea for our environment in any case). But as complicated as the ProxySQL undertaking is, fixing the decades-old, poorly architected, monolithic legacy Java application with library versions EOL'd over a decade ago and tons of SQL queries that rely on old MySQL misfeatures would be far more time-consuming and sometimes difficult enough to the point of infeasibility.
Anyhow, thank you for your answers. They have been extremely helpful and will give us confidence to move forward without worrying too much about the two pools coexisting.
- JK
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
JK,
On 11/24/21 08:03, jklaiho@iki.fi wrote:
>> On Tuesday, Nov 23, 2021 at 4:20 PM, Christopher Schultz <chris@christopherschultz.net (mailto:chris@christopherschultz.net)> wrote:
>>
>> 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.
> Could you expand on this? Connection pooling is a fundamental aspect
> of how ProxySQL operates, after all. I'm not familiar with how the
> DBCP connection pooling works, but what added value would it bring in
> this case? What does DBCP pooling at the application level achieve
> that ProxySQL wouldn't?
The pooling doesn't add anything necessarily to your Java application,
but NOT using the pool can mean that your application could make a
virtually unlimited number of connections to your ProxySQL instance.
The DBCP provides not only "pooling" (that is, re-using of physical
database connections) but also an intentionally-limited resource that
your application can use. If you use a DBCP pool size of 1, only one
thread at a time can make a call to the database. (Well, you could share
the connection across threads, but that would be total chaos.) If you
use an unlimited pool size, then you will allow the application to make
unlimited queries to your ProxySQL instance.
Perhaps you want to limit the number of simultaneous connections to the
physical database to something reasonable, like 100. So you set that up
in ProxySQL so you have a pool size of 100. Any number of clients can
connect and query, but you'll only be actively executing at most 100. So
there is no reason to allow more than 100 incoming connections to ProxySQL.
If you get a flood of requests to your application and every single one
of them requires a database connection to complete, you'll get a huge
flood of requests to ProxySQL. All but 100 of those requests will sit
there waiting at ProxySQL, *with a query pending execution*. If the
application times-out waiting for the query to complete, either the user
wil see an error, or the application will try-again. The user will most
likely try again if they see an error. In either case, the query has
been sent to ProxySQL and it probably doesn't know that the client has
given-up, so it has to execute the query anyway. But the client is gone,
so the query is just a waste. You have just launched a DOS against your
database.
If, instead, you configure your DBCP pool size to be 100 / N where N is
the number of application servers you have, then the application stalls
*waiting for the database connection* and not waiting for a query. When
this happens, the error is moved to acquiring the connection and not
issuing the query. So your database never has to process unnecessary
queries.
It's essentially "failing faster" or, IMO, "failing safer."
> In case it's relevant, we're planning on installing ProxySQL on the
> app servers themselves, an approach generally recommended by e.g.
> Percona.
I don't think it's relevant.
> My main fear is that having two separate connection pools would make
> performance tuning at the pool level potentially nightmarish. We'd
> make a config change at the ProxySQL level, test it, and conclude
> that it didn't have a meaningful impact–when it actually might have,
> had there not been another, poorly understood (by us, that is) pool
> at play. DBCP has the potential to muddy the waters: even if it
> doesn't actively work against ProxySQL-level tuning, we can't really
> prove that it's not a contributing cause any time one of our ProxySQL
> config changes fails to improve performance.
I'm sure there is a use-case for ProxySQL, but I find that SQL workloads
fall into a few big categories:
1. Lots of writes. Caches essentially cannot handle this, *especially*
when they are distributed (which is what you have when ProxySQL is
running on the application servers, separately). ProxySQL is not
helpful, here.
2. Few writes, lots of reads. In this case, caching in the application
makes more sense to me than constantly requesting the data from the
database. Not only do you avoid the actual call to the database, but you
also avoid the necessary conversion between the database's data-model
and the application's data model. ProxySQL is not helpful, here, either.
If I were you, I'd examine the reason behind your decision to use
ProxySQL in the first place. Maybe it makes sense to use it, but maybe
it makes sense to use what you already have, and not introduce a new
component into the mix.
>>> 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.
>
> Elsewhere in this thread, Mark Thomas said this in response to Olaf
> Kock, referring to his idea of a custom "non-pooling connection pool":
>
>>> DBCP looks exactly like a database driver to the application. [...]
>>> just configure the database driver directly.
This will work, and you won't get a connection pool at all in your
Tomcat/application. But it will behave as though you have a
connection-pool with an unlimited number of connections, since every
time the application requests a connection, it will get one, opened to
your ProxySQL instance. You can limit the number of connections to
ProxySQL, I suppose, but then you trade "pool borrow timeout" errors for
"connection refused" errors. You also have to construct a new network
connection for each "use" of a db connection in the application. Part of
the reason to use a connection pool (at any level) is to maintain the
open network connection between the application and the database. By
disabling the pool available to the application, you are reducing
performance in a place where a performance drop is completely unnecessary.
> Now, this probably shouldn't be taken as a recommendation or even a
> statement of practical feasibility. How do you view this option,
> assuming local ProxySQL installs on the app servers? You can still
> assume my complete ignorance about every element between the JNDI
> specs and the actual configuration statements in context.xml :-)
Performance tuning is a Dark Art. You are right that if you have two
pools in-place, you may find that tuning one of them is difficult in the
presence of the other. But because you *know* that both exist, you don't
have to do that tuning in a vacuum: you can take both pools into account
when tuning that particular part of your application. Or, you can decide
that you only need one (architecturally speaking) pool at all. And my
argument is that the only pool you need is already configured and ready
to go.
YMMV
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by "jklaiho@iki.fi" <jk...@iki.fi>.
> On Tuesday, Nov 23, 2021 at 4:20 PM, Christopher Schultz <chris@christopherschultz.net (mailto:chris@christopherschultz.net)> wrote:
>
> 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.
Could you expand on this? Connection pooling is a fundamental aspect of how ProxySQL operates, after all. I'm not familiar with how the DBCP connection pooling works, but what added value would it bring in this case? What does DBCP pooling at the application level achieve that ProxySQL wouldn't?
In case it's relevant, we're planning on installing ProxySQL on the app servers themselves, an approach generally recommended by e.g. Percona.
My main fear is that having two separate connection pools would make performance tuning at the pool level potentially nightmarish. We'd make a config change at the ProxySQL level, test it, and conclude that it didn't have a meaningful impact–when it actually might have, had there not been another, poorly understood (by us, that is) pool at play. DBCP has the potential to muddy the waters: even if it doesn't actively work against ProxySQL-level tuning, we can't really prove that it's not a contributing cause any time one of our ProxySQL config changes fails to improve performance.
> > 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.
Elsewhere in this thread, Mark Thomas said this in response to Olaf Kock, referring to his idea of a custom "non-pooling connection pool":
> > No need for this.
> >
>
> > DBCP looks exactly like a database driver to the application. So, rather
> >
> >
> >
>
> > than configuring DBCP as a wrapper for the database driver, you just
> >
> >
>
> > configure the database driver directly.
> >
> >
>
> >
> > The short version is:
> > - remove the pooling configuration from the resource definition
> >
> >
>
> > - change / set the factory attribute the the correct value for your
> >
> >
>
> > driver (probably com.mysql.cj.jdbc.MysqlDataSourceFactory)
> >
> >
>
Now, this probably shouldn't be taken as a recommendation or even a statement of practical feasibility. How do you view this option, assuming local ProxySQL installs on the app servers? You can still assume my complete ignorance about every element between the JNDI specs and the actual configuration statements in context.xml :-)
- JK
Re: Handling database connection pooling outside Java, without DBCP et al?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
JK,
On 11/23/21 08:23, jklaiho@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org