On 29/05/2024 13:38, Eric Robinson wrote:
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
<snip/>
I intend to wok on a patch for Tomcat that will add caching that should
speed things up considerably. I hope to have something for Eric to test
today but it might take me until tomorrow as I have a few other time
critical things fighting to get tot he top of my TODO list at the moment.
Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may
also be a short-term fix but is likely to create problems if the same
JAR ever exists in both locations at the same time.
Just an FYI. On further reflection, moving the JDBC driver JARs isn't
going to help. Sorry. You'll need my fix.
Assuming, of course, you are willing to test a patch to address this on
a production system.
That's some great sleuthing and the explanation makes a ton of sense. It leaves
me with a couple of questions.
If you are correct, then it follows that historic activity has been hovering
dangerously near the threshold where this symptom would manifest. Within the
past month, an unknown change in the system climate now causes an uptick in the
number of DB requests/second at roughly the same time daily (with occasional
exceptions) and the system begins to trip over its own feet. I haven't seen
anything in my Zabbix graphs that stood out as potentially problematic. Armed
with this information, I am now taking a closer look.
Ack.
The natural next question is, what changed in the application or the users'
workflow to push activity over the threshold? We'll dig into that.
Could be all sorts of things.
It might just have been coincidence the first time and now the users all
request the data they need at the start of their day in case the problem
happens again. And by doing that they cause the very problem they are
trying to avoid.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
