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.
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.
(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/
(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
Created attachment 15926 [details] JK log. Loglevel=trace See most recent comments
Created attachment 15927 [details] workers.properties
Created attachment 15928 [details] uriworkermap.properties
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.
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.
(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.
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.