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