Jon,

On 6/30/23 17:21, jonmcalexan...@wellsfargo.com.INVALID wrote:
Hi Chris and Rainer,

Just want to add my .02 worth. Having the ability to "Drain" hosts in a Proxy 
configuration would be an awesome boon so you could gracefully take down a "node" for 
maintenance, or even just a restart. Then be able to put it back in action afterwards. :-) Of 
course, only in setups where you are using load-balancing and multiple back-end app servers. :-)

I have a presentation which covers how to do this, including references to automated tools to drain the servers, how to configure Tomcat to participate in that draining, etc.

It's this one from ApacheCon 2015: http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf

-chris

-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, June 30, 2023 2:19 PM
To: users@tomcat.apache.org
Subject: Re: [mod_jk] Is it possible to set the value of a specific attribute 
via
HTTP?

Rainer,

On 6/29/23 17:06, Rainer Jung wrote:
Hi Chris,

Am 29.06.23 um 15:00 schrieb Christopher Schultz:
All,

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?

Thanks,
-chris

[1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do
that.
[2]

https://urldefense.com/v3/__https://github.com/ChristopherSchultz/apa
che-tomcat-
stuff/tree/master/bin/mod_jk__;!!F9svGWnIaVPGSwU!t6oVjPiPK

IiI1py49MyQzz_Jewu0_iQqa6xWLqEokHwNpzvlcQ2qAXIfGvhJsWTS34rA8tgC
_le50_
lUkwrMqUjevlf5d9KD$

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.

Thank you. I figured you would know best :)

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

I wouldn't suggest adding this to mod_jk for exactly the same reason.
But if the feature DID exist, I would have used it :)

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

Does mod_proxy_balancer have this kind of thing? Does it sound like
something worth implementing? mod_jk's support for monitoring and live-
adjustments has always been better than mod_proxy_* IMHO but it is
catching up. Something like this would be very helpful addition.

-chris

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


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


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

Reply via email to