Bug 36102 - jk 1.2.14 - Worker actions do not persist
Summary: jk 1.2.14 - Worker actions do not persist
Alias: None
Product: Tomcat Connectors
Classification: Unclassified
Component: Common (show other bugs)
Version: unspecified
Hardware: Other Windows Server 2003
: P3 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2005-08-09 15:31 UTC by Chuck Sumpter
Modified: 2008-10-05 03:09 UTC (History)
0 users

ISAPI Redirect log (146.05 KB, text/plain)
2005-08-09 15:36 UTC, Chuck Sumpter
uriworkermap.properties (184 bytes, text/plain)
2005-08-09 15:36 UTC, Chuck Sumpter
workers.properties (845 bytes, text/plain)
2005-08-09 15:37 UTC, Chuck Sumpter
Ilustration of the jkstatus page (53.82 KB, image/jpeg)
2005-08-18 16:24 UTC, Chuck Sumpter

Note You need to log in before you can comment on or make changes to this bug.
Description Chuck Sumpter 2005-08-09 15:31:38 UTC
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.
Comment 1 Chuck Sumpter 2005-08-09 15:36:17 UTC
Created attachment 15986 [details]
ISAPI Redirect log
Comment 2 Chuck Sumpter 2005-08-09 15:36:50 UTC
Created attachment 15987 [details]
Comment 3 Chuck Sumpter 2005-08-09 15:37:08 UTC
Created attachment 15988 [details]
Comment 4 Chuck Sumpter 2005-08-16 14:27:44 UTC
Component: Other is getting nowhere.  Back to Connector. This time I'm not going
to accept the "works for me" resolution.  
Comment 5 Mark Thomas 2005-08-16 14:59:11 UTC
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.
Comment 6 Chuck Sumpter 2005-08-16 15:22:35 UTC
(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.   
Comment 7 Rainer Jung 2005-08-17 01:26:04 UTC
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.
Comment 8 Chuck Sumpter 2005-08-17 15:48:38 UTC
(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.  

Comment 9 Mark Thomas 2005-08-17 19:50:38 UTC
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
Comment 10 Chuck Sumpter 2005-08-18 16:24:29 UTC
Created attachment 16097 [details]
Ilustration of the jkstatus page
Comment 11 Chuck Sumpter 2005-08-18 16:25:41 UTC
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. 
Comment 12 Chuck Sumpter 2005-09-07 20:24:50 UTC
Symptoms recreated in Tomcat 5.5.9
Comment 13 Mladen Turk 2005-09-12 14:59:39 UTC
Fixed in the CVS.
Can you try the CVS head if the problem still exists.
Comment 14 Chuck Sumpter 2005-09-12 22:43:05 UTC
(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.