https://issues.apache.org/bugzilla/show_bug.cgi?id=47750
Summary: Loss of worker settings when changing via jkstatus
Product: Tomcat Connectors
Version: 1.2.28
Platform: PC
OS/Version: Windows Server 2003
Status: NEW
Severity: major
Priority: P2
Component: Common
AssignedTo: dev@tomcat.apache.org
ReportedBy: robert.ma...@capita.co.uk
--- Comment #0 from robert.ma...@capita.co.uk 2009-08-27 10:19:06 PDT ---
Running a load-balanced worker with two nodes - configuration is fine, as ISAPI
filter starts up and works correctly.
A change is made to a worker node using the jkstatus page (for example,
stopping node2, then starting it again). This works fine, as the worker stops
correctly, then becomes available again and works fine.
After an amount of time, the mod_jk log shows the ISAPI filter starting again -
presumably this is IIS restarting something, although it doesn't behave the
same as an app pool recycle so not sure what it is or what is triggering it.
When this happens, the log shows the shared memory being reset in the log for
the workers, and what appears to be the shm being updated with the previous
values from the load-balancer worker's memory, although the sequence number
from memory doesn't match the value that was previously reached from performing
the updates via jkstatus:
jk_lb_worker.c (347): syncing shm for lb 'node-lb' from mem (0->1)
The log them shows shared memory for the load-balancer being synced again under
worker maintenance - the sequence numbers do not match, with the value of
p->sequence being the value previously reached from making the jkstatus
changes, while the shm sequence is still 1 as a result of the previous sync.
So the log shows:
jk_lb_worker.c (292): syncing mem for lb 'node-lb' from shm (3->1)
The log then shows that, as a result of this lb sync, the "changed" workers are
then sync'd from the shm. However, as the data structure of the shm has been
reset by the "restart" of the ISAPI filter, the values for that worker are set
to zero. As this includes the max_packet_size, any request to this worker will
be larger than the max packet size of zero and so causes an "error 413 request
entity too large" to be displayed.
The zero'd records display as such for the worker in jkstatus - manually
updating these entries to the correct values allows that worker to function
again.
I have made a small amendment on my system so that any calls to jk_lb_pull will
only occur if the mem sequeunce is less than the shm sequeunce (rather than
just "not equal"), ie.
changed:
if (p->sequence != p->s->h.sequence)
jk_lb_pull(p, JK_TRUE, l);
to:
if (p->sequence < p->s->h.sequence)
jk_lb_pull(p, JK_TRUE, l);
for all instances where jk_lb_pull is called as a result of this conditional.
It seems to have resolved this particular issue and the settings persist
correctly, but not sure if it is actually a correct solution!
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
