I was told by the jk connector component developer to open a new bug here. He closed the one in his queue as works-for-him (see bug # 35901). So here goes... ================================================================= Jk version in use is a 1.2.14 binary. Scenario: open jkstatus in broswer click worker #1, check "Stopped" and "Update Worker". Stat now shows stopped. Open second browser. Navigate to the same jkstatus page. Worker #1 stat is OK. Both browsers are IE5 one located on my workstation, one the browser for a server, so broswer cash should not be involved. The same symptoms are seen in a single browser instance if you click worker #1 again, but not on a simple page refresh.
Created attachment 15986 [details] ISAPI Redirect log
Created attachment 15987 [details] uriworkermap.properties
Created attachment 15988 [details] workers.properties
Component: Other is getting nowhere. Back to Connector. This time I'm not going to accept the "works for me" resolution.
The comments on bug 35901 said start a discussion on tomcat-dev, not open a duplicate bug report. This probably explains why there has been no activity on this bug. I did some testing of this with the latest TC4.1.x from CVS, jk 1.2.14, Apache 2.0.54 & Firefox 1.0.6 when you opened this bug but could not reproduce the issue. Obviously my environment isn't a great match for yours so I didn't bother reporting my results. I should have IIS available in the next few days. I'll retest then with IIS (version TBD) and IE6 but it still won't be an exact match for your environment. It would be good to eliminate some of the variables. If you could repeat your tests using IE6 or Firefox 1.0.6 that would help narrow down the problem. On the subject of browsers are you sure it is IE5 on both client and server? IE5 is rather old to have shipped with Windows 2003.
(In reply to comment #5) Tests repeated on IE6, Netscape 8 and FireFox 1.06. Same results. Sorry about the duplicate bug, didn't catch the "discussion" keyword.
No solution but a remark: The observation, that you don't see the problem when reloading/refreshing the page might come from the fact, that he chang i done via GET request, so refreshing the page again sends the request including all parameters, so the change is applied a second time. I don't know much about IIS, but maybe you can limit the number of threads to some low count (e.g. 5 or 10) and then check the status of the stopped worker not only once or twice but 10 to 20 times and check, if it is non-stopped all the time, or sporadically stopped.
(In reply to comment #7) Your remark started me down a trail that lead to at least a workaround for the "problem". The version of IIS that is available for install (no longer delivered installed) has some enhanced security and performance "features". In typical Microsoft fashion, they make you dig for what they "really did". I tried all kinds of thread pool, memory caching, etc. No luck. Then I remembered IIS5 isolation mode. As soon as I set that switch and restarted the web services, the setting for Disabled in jkstatus held. I'm going to have to research the performance considerations of this, and I would be interested in your input in this arena. Do you think that I should (as I was asked to do before), start a discussion thread in Tomcat-Dev? Being a little un-familiar with the bug resolution, I picked "Remind", change this is you want.
First off, I am no JK expert. A quick Google suggests that some people needed to set the isolation mode to get jk to work whilst others didn't. I would move this to tomcat-dev list and see what response you get. I'll still do my test with IIS and contribute to that discussion if I find anything enlightening.
Created attachment 16097 [details] Ilustration of the jkstatus page
Thanks Mark! One other thing to look for. I noticed that even in IIS5 isolation mode, changes to the load balancing worker aren't exactly smooth. For example: I open the home page of the app running under Tomcat. Click refresh several times quickly and it switches tomcat instances (workers). If we were on tomcat 5, and clustering, it wouldn't be any big deal. But with tomcat 4, the user will loose there session vars. I tried checking the sticky = True, and updating the worker. When I refreshed the page, it 404'd. I closed the browser and the worker displays contained jibberish, but the sticky was reset to False. Screen shot of the jibberish will be attached to the issue. Only a "bounce" of the WWW Pub service got the jkstatus page to display correctly again. Not sure what this has to do with anything, but thought you might like to have any additional "symptoms" I ran across.
Symptoms recreated in Tomcat 5.5.9
Fixed in the CVS. Can you try the CVS head if the problem still exists.
(In reply to comment #13) > Fixed in the CVS. > Can you try the CVS head if the problem still exists. Actually, I can't try the CVS head, primarily because I have no clue what that is. Sorry, but saying anything else would be counterproductive.