Hi Chris,
Am 20.07.2018 um 16:29 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
I've got a lb worker with two balanced nodes. One of the nodes has a
non-zero value for the "Err" (errors) field, but there is a blank
entry for the "LE" (last error timestamp) field.
I'm using mod_jk 1.2.41 on x86-64 Linux.
The whole XML record (with some things redacted is here):
<jk:member name="my-node" type="ajp13" host="localhost" port="7115"
address="127.0.0.1:port" source="undefined"
connection_pool_timeout="60" ping_timeout="10000" connect_timeout="0"
prepost_timeout="0" reply_timeout="0" connection_ping_interval="0"
retries="2" recovery_options="0" busy_limit="0" max_packet_size="8192"
activation="ACT" lbfactor="1" route="my-node" redirect="" domain=""
distance="0" state="OK" lbmult="1" lbvalue="192" elected="323181"
sessions="13277" errors="21" client_errors="2" reply_timeouts="0"
transferred="322498984" read="1805149172" busy="0" max_busy="222"
connected="26" max_connected="222" time_to_recover_min="0"
time_to_recover_max="0" last_reset_at="1531625678"
last_reset_ago="470720"/>
I don't see any information about the "last error timestamp" in the
raw data. Does this field actually exist?
At least there is code in jk_status.c to handle it. And if it is empty
in the HTML view, the same condition will drop it from the other views.
But it works different for a rway AJP worker and an lb member:
- raw AJP worker (not in an lb):
The underlying field is a "volatile time_t error_time" defined in
jk_shm.h as part of the struct jk_shm_ajp_worker.
It gets set in jk_ajp_common.c to time(NULL) whenever either an AJP
worker goes into error state or its busy count is above the limit. The
field never gets reset.
It is used in jk_status.c to print the LE column and also for XML and
properties output.
- AJP worker as a member in an lb:
The underlying field is a "volatile time_t first_error_time" defined in
jk_shm.h as part of the struct jk_shm_lb_sub_worker.
It gets set in jk_ajp_common.c to time(NULL) whenever either an AJP
worker goes into error state or its busy count is above the limit. The
field gets reset when a worker leaves the error state (probably the case
in your situation) and when you reset the worker statistics via the
status worker. The fields can get set before the worker goes into error,
namely if error_escalation_time allows to ignore errors for some time
before setting an erred worker into error state.
All in all I would say the filed is less useful for lb members than for
raw AJP workers.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org