Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
Hi, I've been asking some more questions about restarts on the Apache list, and was redirected back here... Does anyone know (David, Mladen?) what will happen to session affinity is this situation? ie with Apache in front of several tomcats using mod_jk, when Apache is restarted gracefully using apache -k restart (Windows) will session affinity be preserved across the restart? ie will browsers with a session open with a particular Tomcat continue being directed to that particular Tomcat after the restart? cheers, David |-+ | | David Rees | | | [EMAIL PROTECTED]| | | m | | || | | 05/25/2005 02:37 | | | PM | | | Please respond to| | | Tomcat | | | Developers List | | || |-+ ---| | | | To: Tomcat Developers List tomcat-dev@jakarta.apache.org | | cc: | | Subject: Re: Adding working dynamically with mod_jk status? | ---| On 5/25/05, [EMAIL PROTECTED] wrote: Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? We'd *really* like to find a way around having to force a restart. Have you seen if a graceful restart of Apache works for you? Graceful restarts of Apache have worked for me in the past to add new workers without dropping requests. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: *SPAM* Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
On 6/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone know (David, Mladen?) what will happen to session affinity is this situation? ie with Apache in front of several tomcats using mod_jk, when Apache is restarted gracefully using apache -k restart (Windows) will session affinity be preserved across the restart? ie will browsers with a session open with a particular Tomcat continue being directed to that particular Tomcat after the restart? Session affinity is determined by the suffix of the jsessionid cookie which is stored on the client, so yes, session affinity will be retained across Apache restarts (graceful or not). -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
[EMAIL PROTECTED] wrote: Hi, I've been asking some more questions about restarts on the Apache list, and was redirected back here... Does anyone know (David, Mladen?) what will happen to session affinity is this situation? ie with Apache in front of several tomcats using mod_jk, when Apache is restarted gracefully using apache -k restart (Windows) will session affinity be preserved across the restart? ie will browsers with a session open with a particular Tomcat continue being directed to that particular Tomcat after the restart? First of all graceful restart will not work on Windows for any busy server. I suggest that you move to some unix/linux version. And yes, the session affinity will be preserved because it is related to the worker name and jvmRoute. Also, like somebody already told you: The easiest is to try by yourself, and then come up with the real problem. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
First of all graceful restart will not work on Windows for any busy server. I suggest that you move to some unix/linux version. Errr...could you explain why? I was told on the Apache list that it does work on Windows...what am I missing? cheers, David |-+ | | Mladen Turk | | | [EMAIL PROTECTED]| | | | | || | | 06/07/2005 01:37 | | | PM | | | Please respond to| | | Tomcat | | | Developers List | | || |-+ ---| | | | To: Tomcat Developers List tomcat-dev@jakarta.apache.org | | cc: | | Subject: Re: Session Affinity after Graceful Apache restart? [was Re: Addingworking dynamically | |with mod_jk status?] | ---| [EMAIL PROTECTED] wrote: Hi, I've been asking some more questions about restarts on the Apache list, and was redirected back here... Does anyone know (David, Mladen?) what will happen to session affinity is this situation? ie with Apache in front of several tomcats using mod_jk, when Apache is restarted gracefully using apache -k restart (Windows) will session affinity be preserved across the restart? ie will browsers with a session open with a particular Tomcat continue being directed to that particular Tomcat after the restart? First of all graceful restart will not work on Windows for any busy server. I suggest that you move to some unix/linux version. And yes, the session affinity will be preserved because it is related to the worker name and jvmRoute. Also, like somebody already told you: The easiest is to try by yourself, and then come up with the real problem. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
[EMAIL PROTECTED] wrote: First of all graceful restart will not work on Windows for any busy server. I suggest that you move to some unix/linux version. Errr...could you explain why? I was told on the Apache list that it does work on Windows...what am I missing? It works of course, but IIRC you are planning to use it for reconfiguring mod_jk. I think you might get into the problems with shared memory (particularly on unix) because some child might have a different idea about shared memory addresses. If you do not delete any worker and add new one at the end of the worker.list it might work. Anyhow it's not something I would use in the production and rely on its proper behavior. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
At 02:08 PM 6/7/2005, Mladen Turk wrote: It works of course, but IIRC you are planning to use it for reconfiguring mod_jk. I think you might get into the problems with shared memory (particularly on unix) because some child might have a different idea about shared memory addresses. Oh - so this is a bug/design flaw in mod_jk? Does the same affect the prefork/worker MPMs? One aspect is inheritance of handles (e.g. handle to SHM segment). I've always ment to make that more generic, and it would be nice to solve for Apache 2.2. It's used now to hand of the score and listener handles from the parent to child. The trivial solution is to use an anon segment which Win32 will not inherit, which means that SHM is unique to a single generation, and won't be polluted by changes in another worker. This does sound like a good use case, though, for handing off memory segments, mutexes and so forth to child processes. With a pointer or two, I'll be happy to look at it. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
William A. Rowe, Jr. wrote: At 02:08 PM 6/7/2005, Mladen Turk wrote: It works of course, but IIRC you are planning to use it for reconfiguring mod_jk. I think you might get into the problems with shared memory (particularly on unix) because some child might have a different idea about shared memory addresses. Oh - so this is a bug/design flaw in mod_jk? Does the same affect the prefork/worker MPMs? Actually the WIN32 has no such problems because it uses the plain memory instead of shared. Problem with WIN32 is because the closing child and new child will not share the worker data during restart, so you will loose the statistics during restart. With unixes the problem is because the workers are allocated according to the worker.list and balance_members. If you change those lists in the config on restart the child processes could have different shared memory segment addresses. Like said if you only add to the end of list then everything will probably be OK. To resolve that we would actually need a database like shared memory with worker name as a key. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]