Hi Chris,

Am 29.06.23 um 15:00 schrieb Christopher Schultz:

I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker.

One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system.

The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time.

For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down).

Is there a way to decrement the "errors" count without resetting all counters back to zero?


[1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that.
[2] https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin/mod_jk

no, there is no way to change insdividual runtime counters. As always it would be possible to code it as an addition to the jk manager. One would have to think about which counters for which workers (lb, member, ajp) and whether one should be able to reset to 0, to adjust by some delta or whatever.

I have not immediate intention to implement it, at this point just wanted to mention it is not there but doable.

Since I try to push people into mod_proxy, I am hesitant to implement more and more features which keep people from switching ;)

The last feature I added was putting a request id on the log lines (yet unreleased).



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

Reply via email to