Updated Howto: Setting up BigIP for JSESSIONID-Based Persistence
I updated the HOWTO: Set Up JSessionID-Based Persistence on a BigIP article recently to reflect some additional changes/discoveries made while running this in a production environment for a while. The howto covers migrating off of apache/mod_jk to apache/mod_proxy and moving persistence based on jsessionid to a bigip ltm.
If you are a developer reading this and wondering why in the world anyone would want to move away from mod_jk, the rationale behind the migration is pretty straightforward: When you have more than a couple web servers front-ending your tomcat, glassfish, or jboss application servers, or even if you only have a couple of web servers but a lot of workers defined within your workers.properties files, disabling servers using the jk-status handler page can be a real hassle. Training 1st or 2nd level support personnel within your network operations center on disabling servers in a bigip is much easier than showing them how to disable workers within a jk-status page.
In addition, the BigIP enables the DevOp or Application Delivery Engineer to create more sophisticated health checks to assess app server health over mod_jk's cping/cpong. A well written health monitor on the bigip is much better able to assess if an app server is hung than mod_jk's health checks at present. A BigIP health check can assess almost instantly when a java application server is hung where requests using the traditional mod_jk approach must wait until the ajp backlog threshold has been reached, which could result in a lot of request hitting a hung application server unnecessarily.
Changes to the document include information on why oneconnect is necessary as well as mod_proxy-specific environment variables that should be set in order to avoid 502-Proxy Errors showing up in your apache error log during periods of low site activity.