Bug 35901 - jk 1.2.14 - Worker stop action does not hold
jk 1.2.14 - Worker stop action does not hold
Status: RESOLVED WORKSFORME
Product: Tomcat Connectors
Classification: Unclassified
Component: Common
unspecified
PC Windows Server 2003
: P2 critical (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-07-27 17:47 UTC by Chuck Sumpter
Modified: 2008-10-05 03:08 UTC (History)
0 users



Attachments
JK log. Loglevel=trace (146.05 KB, text/plain)
2005-08-05 22:06 UTC, Chuck Sumpter
Details
workers.properties (845 bytes, text/plain)
2005-08-05 22:07 UTC, Chuck Sumpter
Details
uriworkermap.properties (845 bytes, text/plain)
2005-08-05 22:07 UTC, Chuck Sumpter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chuck Sumpter 2005-07-27 17:47:20 UTC
Jk version in use is a 1.2.14 binary.

Scenario: jkstatus page opens, click worker #1, check "Stopped" and "Update
Worker".  Stat now shows stopped. 

Open second browser (on a server).  Navigate to the same jkstatus page.  Worker
#1 stat is OK.

Both browsers are IE5.
Comment 1 Rainer Jung 2005-08-01 21:17:47 UTC
Maybe your shared memory setup for mod_jk is not correct. Could you post mod_jk
configuration (e.g. workers.properties) and the Jk directives from httpd.conf?

Which web server are you using (type and version)?

I assume mod_jk (i.e. the web server) is running on Win2003?

You should also set JkLogLevel to trace and post the part of the JkLogFile from
accessing /status with correct information, then changing the stopped, until
accessing /status and again seeing the worker non-stopped.
Comment 2 Chuck Sumpter 2005-08-01 23:00:48 UTC
(In reply to comment #1)
> Maybe your shared memory setup for mod_jk is not correct. Could you post 
mod_jk
> configuration (e.g. workers.properties) and the Jk directives from httpd.conf?
> Which web server are you using (type and version)?
> I assume mod_jk (i.e. the web server) is running on Win2003?
> You should also set JkLogLevel to trace and post the part of the JkLogFile 
from
> accessing /status with correct information, then changing the stopped, until
> accessing /status and again seeing the worker non-stopped.

I thought I'd given the environment, but let me try again.  The server OS is 
Win2003.  The JK (ISAPI) plugin has been configured according to 
http://jakarta.apache.org/tomcat/connectors-doc/howto/iis.html

I wondered what happened to the shm, expecting something similar to the one 
used by jk2, but could find no reference to it in any of the how-to doc. Or the 
doc with the source code.  

I will defer the config and log postings until the issue of shared memory in 
the jk1.2.14 is resolved. 

BTW - URL for the binary dist that I used was: 

http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/jk-
1.2.14/
Comment 3 Chuck Sumpter 2005-08-02 15:13:18 UTC
(In reply to comment #1)
> Maybe your shared memory setup for mod_jk is not correct. Could you post mod_jk
> configuration (e.g. workers.properties) and the Jk directives from httpd.conf?
> 
> Which web server are you using (type and version)?
> 
> I assume mod_jk (i.e. the web server) is running on Win2003?
> 
> You should also set JkLogLevel to trace and post the part of the JkLogFile from
> accessing /status with correct information, then changing the stopped, until
> accessing /status and again seeing the worker non-stopped.
> 



FYI - according to the Apache Jakarta Tomcat Connectors change log ...

"Added shared memory to allow dynamic configuration. Shared memory is needed
only for unix platform and web servers having multiple child processes. For
Apache web server two new directives has been added (JkShmFile and JkShmSize).
(mturk)" 

See: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/changelog.html
Comment 4 Chuck Sumpter 2005-08-05 22:06:43 UTC
Created attachment 15926 [details]
JK log.  Loglevel=trace

See most recent comments
Comment 5 Chuck Sumpter 2005-08-05 22:07:08 UTC
Created attachment 15927 [details]
workers.properties
Comment 6 Chuck Sumpter 2005-08-05 22:07:37 UTC
Created attachment 15928 [details]
uriworkermap.properties
Comment 7 Chuck Sumpter 2005-08-05 22:09:53 UTC
Attached log reflect the following activity. 

Opened jkstatus in browser.  Clicked on apj13 Tomcat1.  Checked the Disabled
check box.  Clicked Update Worker.  tomcat1 stat=Disabled. 

Opened jkstatus in second browser.  tomcat1 stat=OK.
Comment 8 Mladen Turk 2005-08-08 17:05:45 UTC
This works although it might give some problems with already
opened browsers and hitting 'refresh'.

If you open a new browser instance the values will be shown correctly.
Even for the existing browsers the correct values will be shown after
60 seconds, and that depends on the browser itself an how it deals with
'Pragma: no-cache' header.

I see this as irrelevant for any 'normal' usage of the lb manager.
Comment 9 Chuck Sumpter 2005-08-08 17:21:04 UTC
(In reply to comment #8)
> This works although it might give some problems with already
> opened browsers and hitting 'refresh'.
> 
> If you open a new browser instance the values will be shown correctly.
> Even for the existing browsers the correct values will be shown after
> 60 seconds, and that depends on the browser itself an how it deals with
> 'Pragma: no-cache' header.
> 
> I see this as irrelevant for any 'normal' usage of the lb manager.
> 

A Browser refresh retained the settings after the use of the Disabled check box
and the Update Worker button.  

"values will be shown correctly".  Do you mean by this, that the
workers.properties will be read and those values displayed.  If this is true,
then the update worker dynamically is pretty worthless. 

"'Pragma: no-cache' header" The application I support uses this header. We've
never had any problems with it. 

"I see this as irrelevant for any 'normal' usage of the lb manager." One has to
wonder what you call 'normal'?  

Let me frame my response from the perspective of someone moving from JK2 to
jk1.2.14.  We made heavy use of the Disabled flag in the workers2.properties to
shut off new sessions to a worker (jvmroute).  Under JK2, when this setting was
changed and the reset link used on the jkstatus page, the disabled setting was
retained until changed.  

My expectations for jk1.2.14 were that it would act in a similar manner.  If
that was a bad assumption, then what does dynamic configuration mean.  I've read
every scrap of doc I can find on this topic.  If I missed something, please
point me to where this is discussed.
Comment 10 Mladen Turk 2005-08-08 17:32:52 UTC
Please do not reopen this case.
If you think that this is still a problem then open a thread on
the tomcat-dev@.

All that I can say is that it works for me. If I update any param it
is correctly shown in the browser.
It is also correctly shown in any newly opened browser. I agree that there
might be problems with already opened browsers, but I really have no idea
why, and like said, I suspect it has to be related with browser catching
the data.