Affects: Release Notes project_key: JBPAPP6 I have one Httpd instance balancing two EAP instance. I try to manipulate mod_jk settings via jkmanager API but it doesn't work. I execute smth. like: Setting sticky session http://127.0.0.1:5080/jkmanager/?cmd=edit&mime=prop&w=router&sticky_session=1 http://127.0.0.1:5080/jkmanager/?cmd=update&mime=prop&w=router&sticky_session=1 Disabling the node worker1 http://127.0.0.1:5080/jkmanager/?cmd=edit&mime=prop&w=router&sw=worker1&vwa=1 http://127.0.0.1:5080/jkmanager/?cmd=update&mime=prop&w=router&sw=worker1&vwa=1 ... But new settings is not applied. Either settings done through the web interface is not applied - http://127.0.0.1:5080/jkmanager. Described features worked in EAP ER3.
Mladen, can you please take a look? Thanks!
Sorry, I meant to send this to Mladen.
Labels: Removed: connectors mod_jk native Added: connectors eap6_need_triage mod_jk native
This works for me: $ echo "GET /jkstatus/?cmd=update&from=show&w=loadbalancer&vlr=5&vlri=100&vlt=60&vlee=30&vlx=0&vls=on&vlm=0&vll=1&mime=txt" | nc 127.0.0.1 8008 Result: type=OK message="Action finished" ... and the status is updated. It also works for any browser, but it doesn't with curl (or I didn't find correct parameters) If you think this is a bug, file a ticket upstream in ASF buzgilla.
OK, so it works with curl as well. The trick is to use the: $ curl -G -d "cmd=update&w=loadbalancer&vlr=3&vlri=100&vlt=60&vlee=30&vlx=0&vls=on&vlm=0&vll=1&mime=txt" 127.0.0.1:8008/jkstatus/?cmd=update Result: type=OK message="Action finished" So the option -G and -d must be used. $ curl -G -d "cmd=dump&w=loadbalancer&mime=xml" 127.0.0.1:8008/jkstatus/
Applied a patch that should fix those shared memory sync issues. Please verify with the mod_jk.so from the latest build RHEL-6: https://brewweb.devel.redhat.com//buildinfo?buildID=213154 Windows: https://brewweb.devel.redhat.com//buildinfo?buildID=213153 Solaris: http://www.qa.jboss.com/xbuildroot/packages/mod_jk/1.2.35/3.sun10/ If OK, we'll rebuild jboss-eap-native-webserver-connectors packages
I tried it, but it still does not work. RHEL6 x86 worker.web_server=Apache/2.2.15 (Unix) DAV/2 mod_jk/1.2.35 worker.jk_version=mod_jk/1.2.35
Thanks Mladen for the RHEL 6 build, just a note that the RHEL-5 build (mod_jk-1.2.35-5.ep6.el5) has also been updated with the patch. The next handoff is tomorrow, let's see if we can get this fixed for that. Thanks!
OK, so the problem is the command usage. The cmd=dump will show only the 'mod_jk.conf' data, not the data from shared memory. It's usage is to monitor modifications of conf files. To see the actual data use: $ curl -G -d "cmd=update&mime=prop&w=router&vls=1" 127.0.0.1:5080/jkmanager/ ... $ curl -G -d "mime=prop" 127.0.0.1:5080/jkmanager/ ... >>> worker.router.sticky_session=True ... So it works.
Mladen, Thank you. I tested it and it really works. Just to be sure I tried another command - disable node, but node is still up. Disable worker1 $ curl -G -d "cmd=update&mime=prop&w=router&sw=worker1&vwa=1" 127.0.0.1:5080/jkmanager/ OR $ curl -G -d "cmd=edit&mime=prop&w=router&sw=worker1&vwa=1" 127.0.0.1:5080/jkmanager/ ... To see state of actual nodes $ curl -G -d "mime=prop" 127.0.0.1:5080/jkmanager/ | grep state ... >> worker.worker1.state=OK/IDLE >> worker.worker2.state=OK/IDLE And true is that worker1 still serving. I tried that on RHEL6x64 (dev57) with old version even new version of from brew: 01794da0e8b1dafd360054bedc4e69c8 mod_jk.so
Hmm, But sate show the connection state. What's got changed is worker.node1.activation=ACT to worker.node1.activation=DIS
jboss-eap6-compose-6.0.0-14.ep6.el6 built with the latest JK with this fixed. Will be part of ER7 handoff.
Triaged by EAP PM team. Changing to Blocker for EAP 6
Will be Resolved in ER7.
Mladen, It works. I was binding on wrong address with one of the EAPs instances (shame on me). Btw. I have noticed one thing. If I want modify some params with cmd "edit" the data are not saved, but with "update" it works correctly. I would expect that "only one" difference between edit and update is that changes with update does not persist restart of httpd, correct? Example of that: curl -G -d "cmd=edit&mime=prop&w=router&sw=worker1&vact=50" 127.0.0.1:5080/jkmanager/ curl -G -d "mime=prop" 127.0.0.1:5080/jkmanager/ | grep connect_timeout >> worker.worker1.connect_timeout=10000 curl -G -d "cmd=update&mime=prop&w=router&sw=worker1&vact=50" 127.0.0.1:5080/jkmanager/ curl -G -d "mime=prop" 127.0.0.1:5080/jkmanager/ | grep connect_timeout >> worker.worker1.connect_timeout=50
For command line tools zou should use 'update' Edit command is (although name suggest it edits) for displaying edit page and is used for web browsers.
Ok, that makes sense. Thanks for the clearing this.
Thank you all for collaboration.
Reopening to set release note fields.
Release Notes Docs Status: Added: Not Yet Documented Affects: Added: Release Notes
Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Resolved Issue Release Notes Text: Added: Apache <code>mod_jk</code> includes a status manager API. When operations were run with it, the changes were not applied. This occurred via the API and the JK Status Manager web interface. This was due to an error with shared memory synchronization. This error has been corrected, and the JK Manager works as expected.
Issue appears once again in 6.0.0.GA (I'm editing affected version of this jira as well)
Attachment: Added: mod_jk.log
Writer: Added: mistysj
Release Notes Docs Status: Removed: Documented as Resolved Issue Added: Documented as Known Issue
Release Notes Text: Removed: Apache <code>mod_jk</code> includes a status manager API. When operations were run with it, the changes were not applied. This occurred via the API and the JK Status Manager web interface. This was due to an error with shared memory synchronization. This error has been corrected, and the JK Manager works as expected. Added: Apache <code>mod_jk</code> includes a status manager API. When operations are run with it, the changes are not applied, whether initiated via the API or the JK Status Manager web interface. This is due to an error with shared memory synchronization.
Release Notes Text: Removed: Apache <code>mod_jk</code> includes a status manager API. When operations are run with it, the changes are not applied, whether initiated via the API or the JK Status Manager web interface. This is due to an error with shared memory synchronization. Added: Apache mod_jk includes a status manager API. When operations are run with it, the changes are not applied, whether initiated via the API or the JK Status Manager web interface. This is due to an error with shared memory synchronization.
I confirm, that problem still appears. In details - enabling / disabling workers with mentioned URL or via web interface - WORKS - enabling / disabling of sticky session WORKS via URL (like jkmanager?cmd=update&mime=prop&w=router&vls=0|1) but doesn't via web interface. It is only possible to set sticky session but it is not possible disable it via web interface. Is there any reason why we use mod_jk 1.2.36 since 1.2.37 is out?
Our 1.2.36 is actually 1.2.37 (we have a patch that is basically a diff between 1.2.37 and 1.2.36) It was part of JBPAPP-9164, but it doesn't solve all the issues, so this is left for upstream fix first.
Release Notes Docs Status: Removed: Documented as Known Issue Writer: Removed: mistysj Release Notes Text: Removed: Apache mod_jk includes a status manager API. When operations are run with it, the changes are not applied, whether initiated via the API or the JK Status Manager web interface. This is due to an error with shared memory synchronization. Docs QE Status: Removed: NEW
Ok, accurate situation about mass nodes handling is: - enabling / disabling workers with mentioned URL or via web interface - WORKS on Windows and Solaris, but not on RHEL.
This issue is still valid. I belive that is relevant to https://bugzilla.redhat.com/show_bug.cgi?id=900793 Problem described for EWS is present for EAP natives too. The problem obviously emerged on RHEL until 6.1.0.ER5, now appears on Solaris too (when httpd distributed in EAP is used).
Vaclav and Permaine, We just discovered that there is following patch http://svn.apache.org/viewvc?view=revision&revision=1354021 for resolving this issue. Could you please incorporate it to EAP6 ER7 build?
Please check comment 35.
ER7 natives were already staged and waited on hand-off to QE at that time. If there will be additional release, we could incorporate it.
Thank you. Verified with EAP 6.1.0.ER8 -> OK