Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-05-08 Thread Georg von Zezschwitz
Ruediger Pluem wrote: -for (i = 0; i arr-nelts; i++) { -const char *err = set_balancer_param(conf, cmd-pool, balancer, elts[i].key, - elts[i].val); +else { +if (params-nelts 0 +

AW: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-05-08 Thread Plüm , Rüdiger , VF-Group
-Ursprüngliche Nachricht- Von: Georg von Zezschwitz Gesendet: Dienstag, 8. Mai 2007 10:05 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer You declare a balancer: Proxy balancer://mycloud BalancerMember ajp://192.168.1.1:5001

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-05-08 Thread Jean-Frederic
On Mon, 2007-05-07 at 21:05 +0200, Ruediger Pluem wrote: On 05/07/2007 05:56 PM, Mladen Turk wrote: I think we could use a simple two use case situation. To be able to backport that to the 2.2 branch I propose a following patch. It adds additional struct member sticky_path that

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-05-07 Thread Ruediger Pluem
On 04/06/2007 01:13 PM, Georg von Zezschwitz wrote: Jim Jagielski wrote: If we state that the evaluation takes place in the occurence of stickysession attributes and suggest stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to the user it will perform faster in

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-05-07 Thread Mladen Turk
Ruediger Pluem wrote: On 04/06/2007 01:13 PM, Georg von Zezschwitz wrote: Jim Jagielski wrote: attached is the patch for trunk with documentation Co. Could anybody review it commit? Many thanks for sending the patch and my apologies that reviewing it took that long. Please find my

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-05-07 Thread Ruediger Pluem
On 05/07/2007 05:56 PM, Mladen Turk wrote: I think we could use a simple two use case situation. To be able to backport that to the 2.2 branch I propose a following patch. It adds additional struct member sticky_path that is set to the sticky so if someone has in the config ...

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-06 Thread Georg von Zezschwitz
Jim Jagielski wrote: If we state that the evaluation takes place in the occurence of stickysession attributes and suggest stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to the user it will perform faster in average. As I promised to write the patch, I would do it the

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Plüm , Rüdiger , VF-Group
-Ursprüngliche Nachricht- Von: Mladen Turk Gesendet: Dienstag, 3. April 2007 17:25 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer stickysession=JSESSIONID stickysession=;jsessionid stickysession=MYSESSION would mean

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Georg von Zezschwitz
Mladen Turk wrote: ... or perhaps a different notation ... stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION I like that much more - these flags like [C] rather raise questions like can I add multiple of them?. What about this?: stickysession The attribute can occur multiple times

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Mladen Turk
Plüm wrote: 1. You want to change sticky in struct proxy_balancer from const char *sticky to something like const char *sticky[MAX_ENTRIES] Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) Why is FOO stored in balancer-sticky-[2]? Is it because

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Plüm , Rüdiger , VF-Group
Thanks for the clarifications. -Ursprüngliche Nachricht- Von: Mladen Turk Gesendet: Mittwoch, 4. April 2007 13:36 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer Plüm wrote: 1. You want to change sticky in struct

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Jim Jagielski
On Apr 4, 2007, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote: But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. Since the whole idea of loadable lb method

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Mladen Turk
Plüm wrote: Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and would prevent backporting. The other solution is to

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Jim Jagielski
On Apr 4, 2007, at 9:38 AM, Mladen Turk wrote: Plüm wrote: Yes, although MAX_ENTRIES would be 3 for now (cookie, path and env) But this means that we break the ABI here. If struct proxy_balancer is part of a public API (I am not sure about this) this would require a major bump and

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Plüm , Rüdiger , VF-Group
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 4. April 2007 16:16 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer On Apr 4, 2007, at 9:38 AM, Mladen Turk wrote: Plüm wrote: Yes, although MAX_ENTRIES

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Mladen Turk
Plüm wrote: Plus does it make sense to split the sticky string everytime we search for a route? From my performance feeling this split should be done during configuration time. We can use the NUL separated double NUL terminated string. Then a part is start + strlen(start) Regards, Mladen.

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Jim Jagielski
On Apr 4, 2007, at 10:27 AM, Plüm, Rüdiger, VF-Group wrote: Hmmm... I like this idea. Not sure about the use of '/' as the delim (simply because of its other meanings) but that's secondary. Of course, we can't use strtok, since sticky is a const char and we can't be shoving NULLs in there :)

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Jim Jagielski
On Apr 4, 2007, at 11:34 AM, Georg von Zezschwitz wrote: Jim Jagielski schrieb: Rüdiger's point is that we would be doing the scanning for each and every request, which is wasteful since they aren't changing. Even in the above the strlen() is counting chars that don't change between requests.

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-04 Thread Georg von Zezschwitz
Mladen Turk schrieb: ... or perhaps a different notation ... stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION I like that much more - these flags like [C] rather raise questions like can I add multiple of them?. What about this?: stickysession The attribute can occur multiple times

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Mladen Turk
Georg von Zezschwitz wrote: As I (with Rüdigers help :-) ) found out, there is already a bug report to my problem: #41897 describes the problem that the case-sensitivity of the stickysession-Parameter does not comply to the Java Servlet Spec (Cookie: JSESSIONID, url based session

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Jean-Frederic
On Tue, 2007-04-03 at 08:30 +0200, Mladen Turk wrote: Georg von Zezschwitz wrote: As I (with Rüdigers help :-) ) found out, there is already a bug report to my problem: #41897 describes the problem that the case-sensitivity of the stickysession-Parameter does not comply to the

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Plüm , Rüdiger , VF-Group
-Ursprüngliche Nachricht- Von: Jean-Frederic [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 3. April 2007 11:32 An: dev@httpd.apache.org Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer On Tue, 2007-04-03 at 08:30 +0200, Mladen Turk wrote: Georg von

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Mladen Turk
Plüm wrote: IMHO adding config parameters is no blocker for a backport. I was under different perception. It is probably more easy to add balancer-stickyurl = jsessionid when balancer-sticky is JSESSIONID and NULL otherwise. Or in get_path_param() test for jsessionid when

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Jean-Frederic
On Tue, 2007-04-03 at 15:06 +0200, Mladen Turk wrote: Plüm wrote: IMHO adding config parameters is no blocker for a backport. I was under different perception. It is probably more easy to add balancer-stickyurl = jsessionid when balancer-sticky is JSESSIONID and NULL

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Mladen Turk
Jean-Frederic wrote: We could do that then by using existing directive and decide during configure time. For example: stickysession=JSESSIONID [C] stickysession=;jsessionid [P] Does that mean that stickysession=JSESSIONID will work as it does now? Yes. I don't think we need Case

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-03 Thread Georg von Zezschwitz
Mladen Turk schrieb: Georg von Zezschwitz wrote: .. #41897 describes the problem that the case-sensitivity of the stickysession-Parameter does not comply to the Java Servlet Spec (Cookie: JSESSIONID, url based session management ;jsessionid). This is not the breakage of the Servlet-Spec.

Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-02 Thread Georg von Zezschwitz
Hi, As I (with Rüdigers help :-) ) found out, there is already a bug report to my problem: #41897 describes the problem that the case-sensitivity of the stickysession-Parameter does not comply to the Java Servlet Spec (Cookie: JSESSIONID, url based session management ;jsessionid). To solve

Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer

2007-04-02 Thread Mathias Herberts
The message I posted earlier (in march) contains a patch to address this issue. Mathias. On 4/2/07, Georg von Zezschwitz [EMAIL PROTECTED] wrote: Hi, As I (with Rüdigers help :-) ) found out, there is already a bug report to my problem: #41897 describes the problem that the case-sensitivity