Re: Sticky session, dumb client

[Cyril Bonté]

Le samedi 31 octobre 2009 00:28:18, Robinson, Michael a écrit :
> Willy,
> 
> Before trying the workaround, I did use mod_write on Apache in front of 
> HAproxy to change "/app;jsessionid=..." into "/app;JSESSIONID=..."  HAproxy 
> log showed the modified request correctly matched expectations, such that the 
> incoming URL-based cookie name was uppercase JSESSIONID, the outgoing 
> header-based cookie name was also JSESSIONID (and their values matched).  
> Unfortunately, this did not work - could be some other config item I have set 
> incorrectly or possibly some unintended consequence of the rewrite.  

Well, Willy is right, you should put "appsession JSESSIONID" instead of 
"appsession jsessionid". Here, your tried to change the client side parameter 
but, as he said, the problem is on the response side, where the cookie sent is 
JSESSIONID which doesn't match the rule "appsession jsessionid" (the cookie is 
case sensitive, the url parameter not).

I quote here some parts of your previous messages :
> I'm curious about jvmRoute - should I have it set in the tomcat configuration 
> (and, if so, to what)?  Since HAproxy is doing the routing of requests, by 
> the time it hits the frontend there is no more routing required so I don't 
> have jvmRoute set... perhaps this is incorrect?  It does appear my request 
> contains mod_jk-like appended server info to the jsessionid
>
> "POST /app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0"

You said that the jvmRoute was not set but this "mod_jk-like appended server" 
is certainly the jvmRoute configured in the tomcat engine section (see 
server.xml). As there's no loadbalancing between apache and tomcat, I think 
this is not useful and can be removed. Also, haproxy can skip this suffix and 
take into account only the first 32 chars (this will use less memory in the 
haproxy persistence table).

"appsession JSESSIONID len 32 timeout 1h" should work.

I hope that helps you.

-- 
Cyril Bonté

RE: Sticky session, dumb client

[Robinson, Michael]

Willy,

Before trying the workaround, I did use mod_write on Apache in front of HAproxy 
to change "/app;jsessionid=..." into "/app;JSESSIONID=..."  HAproxy log showed 
the modified request correctly matched expectations, such that the incoming 
URL-based cookie name was uppercase JSESSIONID, the outgoing header-based 
cookie name was also JSESSIONID (and their values matched).  Unfortunately, 
this did not work - could be some other config item I have set incorrectly or 
possibly some unintended consequence of the rewrite.  The app passing the 
cookie is Funambol - it is open source, but I don't have the schedule 
flexibility or experience to justify making changes to their code so, in the 
interest of time, I went in the other direction.  FWIW, I've passed along your 
feedback and my workaround to our contact there, perhaps it'll make it into the 
codebase.  Funambol suggests users use mod_jk for load balancing, so no one had 
come across this issue yet...

I appreciate your feedback and will certainly heed your warning about modifying 
requests becoming a nightmare... in time I will seek a "proper" solution 
(knowing, of course, that temporary solutions tend to be the most permanent!)

Kindest regards,

Mike


From: Willy Tarreau [...@1wt.eu]
Sent: Friday, October 30, 2009 2:35 AM
To: Robinson, Michael
Cc: Aleksandar Lazic; haproxy@formilux.org
Subject: Re: Sticky session, dumb client

On Wed, Oct 28, 2009 at 08:43:13PM -0400, Robinson, Michael wrote:
> Thanks again, Aleks and Willy.
>
> This is finally working - not an elegant solution, but as a workaround a 
> SERVERID cookie can be appended onto the request header using Apache 
> mod_header that mimics the one inserted by HAproxy on outgoing responses.  
> So, basically HAproxy sees a "normal" client request, and "cookie SERVERID 
> insert indirect nocache" can work as documented.  This is possible because 
> the jsessionid value passed in the URL has the originating server appended to 
> the session information already (apparently that is what mod_jk uses and our 
> software was originally written with mod_jk in mind).

OK but you apparently did not check what I suggested was wrong in your config,
which is the fact that you are using two different cookies names, "JSESSIONID"
and "jsessionid", which is the reason why it is not matched in the URL.

It should be easier to fix that than to rewrite request parts along the chain
which will become a real nightmare.

Willy

Re: Sticky session, dumb client

[Willy Tarreau]

On Wed, Oct 28, 2009 at 08:43:13PM -0400, Robinson, Michael wrote:
> Thanks again, Aleks and Willy.
> 
> This is finally working - not an elegant solution, but as a workaround a 
> SERVERID cookie can be appended onto the request header using Apache 
> mod_header that mimics the one inserted by HAproxy on outgoing responses.  
> So, basically HAproxy sees a "normal" client request, and "cookie SERVERID 
> insert indirect nocache" can work as documented.  This is possible because 
> the jsessionid value passed in the URL has the originating server appended to 
> the session information already (apparently that is what mod_jk uses and our 
> software was originally written with mod_jk in mind).

OK but you apparently did not check what I suggested was wrong in your config,
which is the fact that you are using two different cookies names, "JSESSIONID"
and "jsessionid", which is the reason why it is not matched in the URL.

It should be easier to fix that than to rewrite request parts along the chain
which will become a real nightmare.

Willy

RE: Sticky session, dumb client

[Robinson, Michael]

Thanks again, Aleks and Willy.

This is finally working - not an elegant solution, but as a workaround a 
SERVERID cookie can be appended onto the request header using Apache mod_header 
that mimics the one inserted by HAproxy on outgoing responses.  So, basically 
HAproxy sees a "normal" client request, and "cookie SERVERID insert indirect 
nocache" can work as documented.  This is possible because the jsessionid value 
passed in the URL has the originating server appended to the session 
information already (apparently that is what mod_jk uses and our software was 
originally written with mod_jk in mind).

Thanks again for the help!

-Mike

-Original Message-
From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
Sent: Wednesday, October 28, 2009 1:12 AM
To: Robinson, Michael
Cc: haproxy@formilux.org
Subject: Re: Sticky session, dumb client

On Die 27.10.2009 20:37, Robinson, Michael wrote:
>Thanks for the reply, Aleks.
>
>appsession lookup in URL does not seem to work for me.

Please can you rebuild haproxy with

DEBUG=-DDEBUG_HASH

and run it with -db to see what's in the hash.

>The request, as it appears in HTTP access_log:
>
>64.88.170.40 - - [28/Oct/2009:00:22:04 +] "POST
>/app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0"
>200 1002 "-" ""
>
>And from haproxy.log:
>
>Oct 28 00:18:20 127.0.0.1 haproxy[18330]: 127.0.0.1:46652
>[28/Oct/2009:00:18:20.441] www www/i-c05ddda8 0/0/0/2/2 200 495 -
>JSESSIONID=7537BF152E4E826BBD0672DE3AC1A4CE.10  0/0/0/0/0 0/0 "GET
>/ HTTP/1.1"

This lines are not from the same client or requst right?!

BR

Aleks

>My haproxy.cfg:
>
>   ...
># when cookie persistence is required
>#cookie JSESSIONID prefix
>appsession jsessionid len 32 timeout 1080
>option httpclose
>capture cookie JSESSIONID len 46
># Example server line (with optional cookie and check included)
>serversrv1 10.253.43.224:8000 cookie srv1 check inter 2000 
> rise 2 fall 3
>serversrv2 10.253.43.224:8000 cookie srv2 check inter 2000 
> rise 2 fall 3
>   ...
>
>Requests are still routed to both servers. It was suggested mod_jk and
>jvmRoute settings may be a factor (which seems true with server ID
>appended onto jsessionid - I don't have jvmRoute set anywhere); perhaps
>I'm overlooking something simple, but there's nothing apparent from the
>documentation I've read.
>
>I tried using the latest dev version of HAproxy too - didn't work.  Thoughts?
>
>Thanks again for the feedback.
>
>Mike
>
>
>
>From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
>Sent: Tuesday, October 27, 2009 2:54 PM
>To: haproxy@formilux.org
>Subject: Re: Sticky session, dumb client
>
>Dear Michael,
>
>On Mon 26.10.2009 21:18, Robinson, Michael wrote:
>>I've got HAproxy 1.3.22 configured on two EC2 servers in front of two
>>Apache/Tomcat frontends serving a JSP-based mobile phone application.
>>The application requires session stickiness - I've tried every
>>documented alternative HAproxy offers for session persistence,
>>unfortunately without luck.  The mobile device (well, our application)
>>does not support cookies and will not echo a modified jsessionid cookie
>>on subsequent requests.  Two options seem ideal, but there are
>>roadblocks:
>>
>>1. appsession jsessionid len 52 timeout 1h
>>
>>However, since cookies aren't an option, we hoped to leverage
>>appsession URL lookup... which has the honor of being on the matrix of
>>all known bugs<http://haproxy.1wt.eu/knownbugs-1.3.html> posted on
>>10/18 (thanks for posting this, BTW!)
>>
>>Any ideas if/when this may make it into a stable release?
>
>It should work in the current release of haproxy.
>Do you have faced some problems, or bugs?
>
>>2. balance url_param jsessionid check_post
>>
>>This option could work... but it doesn't (for me, at least).  Is the
>>config line wrong?  Here's an example HTTP request from our log file:
>>
>>... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1"
>>
>>Can/should I just modify the source for url_param matching to look for
>>';' instead of '?' as a workaround?
>
>This could not work due to the fact that the jsessionid=... is not part
>or query string.
>
>from http://haproxy.1wt.eu/download/1.3/doc/configuration.txt
>
>###
>url_param   The URL parameter specified in argument will be looked up in
>   the query string of each HTTP GET request.
>.
>.
>###
>
>I think it is not a good idea to change the delimiter from ';' to '?'.
>
>Maybe you will be happy with 'uri' as lb method?
>
>Maybe there should be parameter delimiter or regex for the load
>balancing algorithm uri?
>
>E.g.: delimregex ;\\s+jsessionid=([:xdigit:]+) or similar
>
>BR
>
>Aleks
>

Re: Sticky session, dumb client

[Aleksandar Lazic]

On Die 27.10.2009 20:37, Robinson, Michael wrote:

Thanks for the reply, Aleks.

appsession lookup in URL does not seem to work for me.


Please can you rebuild haproxy with

DEBUG=-DDEBUG_HASH

and run it with -db to see what's in the hash.


The request, as it appears in HTTP access_log:

64.88.170.40 - - [28/Oct/2009:00:22:04 +] "POST
/app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0"
200 1002 "-" ""

And from haproxy.log:

Oct 28 00:18:20 127.0.0.1 haproxy[18330]: 127.0.0.1:46652
[28/Oct/2009:00:18:20.441] www www/i-c05ddda8 0/0/0/2/2 200 495 -
JSESSIONID=7537BF152E4E826BBD0672DE3AC1A4CE.10  0/0/0/0/0 0/0 "GET
/ HTTP/1.1"


This lines are not from the same client or requst right?!

BR

Aleks


My haproxy.cfg:

...
   # when cookie persistence is required
   #cookie JSESSIONID prefix
   appsession jsessionid len 32 timeout 1080
   option httpclose
   capture cookie JSESSIONID len 46
   # Example server line (with optional cookie and check included)
   serversrv1 10.253.43.224:8000 cookie srv1 check inter 2000 rise 
2 fall 3
   serversrv2 10.253.43.224:8000 cookie srv2 check inter 2000 rise 
2 fall 3
...

Requests are still routed to both servers. It was suggested mod_jk and
jvmRoute settings may be a factor (which seems true with server ID
appended onto jsessionid - I don't have jvmRoute set anywhere); perhaps
I'm overlooking something simple, but there's nothing apparent from the
documentation I've read.

I tried using the latest dev version of HAproxy too - didn't work.  Thoughts?

Thanks again for the feedback.

Mike



From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
Sent: Tuesday, October 27, 2009 2:54 PM

To: haproxy@formilux.org
Subject: Re: Sticky session, dumb client

Dear Michael,

On Mon 26.10.2009 21:18, Robinson, Michael wrote:

I've got HAproxy 1.3.22 configured on two EC2 servers in front of two
Apache/Tomcat frontends serving a JSP-based mobile phone application.
The application requires session stickiness - I've tried every
documented alternative HAproxy offers for session persistence,
unfortunately without luck.  The mobile device (well, our application)
does not support cookies and will not echo a modified jsessionid cookie
on subsequent requests.  Two options seem ideal, but there are
roadblocks:

1. appsession jsessionid len 52 timeout 1h

However, since cookies aren't an option, we hoped to leverage
appsession URL lookup... which has the honor of being on the matrix of
all known bugs<http://haproxy.1wt.eu/knownbugs-1.3.html> posted on
10/18 (thanks for posting this, BTW!)

Any ideas if/when this may make it into a stable release?


It should work in the current release of haproxy.
Do you have faced some problems, or bugs?


2. balance url_param jsessionid check_post

This option could work... but it doesn't (for me, at least).  Is the
config line wrong?  Here's an example HTTP request from our log file:

... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1"

Can/should I just modify the source for url_param matching to look for
';' instead of '?' as a workaround?


This could not work due to the fact that the jsessionid=... is not part
or query string.

from http://haproxy.1wt.eu/download/1.3/doc/configuration.txt

###
url_param   The URL parameter specified in argument will be looked up in
  the query string of each HTTP GET request.
.
.
###

I think it is not a good idea to change the delimiter from ';' to '?'.

Maybe you will be happy with 'uri' as lb method?

Maybe there should be parameter delimiter or regex for the load
balancing algorithm uri?

E.g.: delimregex ;\\s+jsessionid=([:xdigit:]+) or similar

BR

Aleks

Re: Sticky session, dumb client

[Willy Tarreau]

On Tue, Oct 27, 2009 at 08:37:38PM -0400, Robinson, Michael wrote:
> Thanks for the reply, Aleks.
> 
> appsession lookup in URL does not seem to work for me.
> 
> The request, as it appears in HTTP access_log:
> 
> 64.88.170.40 - - [28/Oct/2009:00:22:04 +] "POST 
> /app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0" 200 
> 1002 "-" ""
> 
> And from haproxy.log:
> 
> Oct 28 00:18:20 127.0.0.1 haproxy[18330]: 127.0.0.1:46652 
> [28/Oct/2009:00:18:20.441] www www/i-c05ddda8 0/0/0/2/2 200 495 - 
> JSESSIONID=7537BF152E4E826BBD0672DE3AC1A4CE.10  0/0/0/0/0 0/0 "GET / 
> HTTP/1.1"
> 
> My haproxy.cfg:
> 
>   ...
> # when cookie persistence is required
> #cookie JSESSIONID prefix
> appsession jsessionid len 32 timeout 1080
> option httpclose
> capture cookie JSESSIONID len 46
> # Example server line (with optional cookie and check included)
> serversrv1 10.253.43.224:8000 cookie srv1 check inter 2000 
> rise 2 fall 3
> serversrv2 10.253.43.224:8000 cookie srv2 check inter 2000 
> rise 2 fall 3
>   ...

Stupid question : is it normal that your cookie name is upper case and
that the url cookie name is lower case ? That's what you have in your
trace too, but I'm fairly certain that cookie names are case-sensitive.

So basically your application is doing a SetCookie: JSESSIONID=xxx and
setting "jsessionid=xxx" in URLs, but those two are different cookies.
Since you have configured appsession to check only jsessionid and it
never sees it in responses, it will never learn it and will never match
it.

You have to fix the application  at this point.

Regards,
Willy

RE: Sticky session, dumb client

[Robinson, Michael]

Thanks for the reply, Cyril.  

Each Apache/Tomcat frontend has 1 apache instance communicating with 1 tomcat 
instance via mod_jk (ajp13).  I'm curious about jvmRoute - should I have it set 
in the tomcat configuration (and, if so, to what)?  Since HAproxy is doing the 
routing of requests, by the time it hits the frontend there is no more routing 
required so I don't have jvmRoute set... perhaps this is incorrect?  It does 
appear my request contains mod_jk-like appended server info to the jsessionid

"POST /app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0"

I tried appsession len=32 but that did not work.  Also, I'd like to avoid 
balance url_param since appsession seems like the "proper" method for session 
affinity.

Thank you again for the suggestions and feedback.

Mike

-Original Message-
From: Cyril Bonté [mailto:cyril.bo...@free.fr] 
Sent: Tuesday, October 27, 2009 1:00 AM
To: Robinson, Michael
Cc: haproxy@formilux.org
Subject: Re: Sticky session, dumb client

Le mardi 27 octobre 2009 02:18:35, Robinson, Michael a écrit :
> I've got HAproxy 1.3.22 configured on two EC2 servers in front of two 
> Apache/Tomcat frontends serving a JSP-based mobile phone application.  

Does 1 apache instance can talk to 1 (and only 1) tomcat or can it talk to both 
tomcat ? How the communication is made between them (mod_jk, 
mod_proxy_ajp/http/balancer) ?


> The application requires session stickiness - I've tried every documented 
> alternative HAproxy offers for session persistence, unfortunately without 
> luck.  The mobile device (well, our application) does not support cookies and 
> will not echo a modified jsessionid cookie on subsequent requests.  Two 
> options seem ideal, but there are roadblocks:
> 
> 
> 1. appsession jsessionid len 52 timeout 1h
> 
> However, since cookies aren't an option, we hoped to leverage appsession URL 
> lookup... which has the honor of being on the matrix of all known 
> bugs<http://haproxy.1wt.eu/knownbugs-1.3.html> posted on 10/18 (thanks for 
> posting this, BTW!)
> 
> Any ideas if/when this may make it into a stable release?

You should try with "len 32" if there's no jvmRoute in the tomcat configuration.

 > 2. balance url_param jsessionid check_post
> 
> This option could work... but it doesn't (for me, at least).  Is the config 
> line wrong?  Here's an example HTTP request from our log file:
> 
> ... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1"
> 
> Can/should I just modify the source for url_param matching to look for ';' 
> instead of '?' as a workaround?

I don't think this will work as the hashed value of jsessionid won't necessarly 
point to the server that provided this session.

-- 
Cyril Bonté

RE: Sticky session, dumb client

[Robinson, Michael]

Thanks for the reply, Aleks.

appsession lookup in URL does not seem to work for me.

The request, as it appears in HTTP access_log:

64.88.170.40 - - [28/Oct/2009:00:22:04 +] "POST 
/app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0" 200 
1002 "-" ""

And from haproxy.log:

Oct 28 00:18:20 127.0.0.1 haproxy[18330]: 127.0.0.1:46652 
[28/Oct/2009:00:18:20.441] www www/i-c05ddda8 0/0/0/2/2 200 495 - 
JSESSIONID=7537BF152E4E826BBD0672DE3AC1A4CE.10  0/0/0/0/0 0/0 "GET / 
HTTP/1.1"

My haproxy.cfg:

...
# when cookie persistence is required
#cookie JSESSIONID prefix
appsession jsessionid len 32 timeout 1080
option httpclose
capture cookie JSESSIONID len 46
# Example server line (with optional cookie and check included)
serversrv1 10.253.43.224:8000 cookie srv1 check inter 2000 rise 
2 fall 3
serversrv2 10.253.43.224:8000 cookie srv2 check inter 2000 rise 
2 fall 3
...

Requests are still routed to both servers. It was suggested mod_jk and jvmRoute 
settings may be a factor (which seems true with server ID appended onto 
jsessionid - I don't have jvmRoute set anywhere); perhaps I'm overlooking 
something simple, but there's nothing apparent from the documentation I've read.

I tried using the latest dev version of HAproxy too - didn't work.  Thoughts?

Thanks again for the feedback.

Mike



-Original Message-
From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
Sent: Tuesday, October 27, 2009 2:54 PM
To: haproxy@formilux.org
Subject: Re: Sticky session, dumb client

Dear Michael,

On Mon 26.10.2009 21:18, Robinson, Michael wrote:
>I've got HAproxy 1.3.22 configured on two EC2 servers in front of two
>Apache/Tomcat frontends serving a JSP-based mobile phone application.
>The application requires session stickiness - I've tried every
>documented alternative HAproxy offers for session persistence,
>unfortunately without luck.  The mobile device (well, our application)
>does not support cookies and will not echo a modified jsessionid cookie
>on subsequent requests.  Two options seem ideal, but there are
>roadblocks:
>
>1. appsession jsessionid len 52 timeout 1h
>
>However, since cookies aren't an option, we hoped to leverage
>appsession URL lookup... which has the honor of being on the matrix of
>all known bugs<http://haproxy.1wt.eu/knownbugs-1.3.html> posted on
>10/18 (thanks for posting this, BTW!)
>
>Any ideas if/when this may make it into a stable release?

It should work in the current release of haproxy.
Do you have faced some problems, or bugs?

>2. balance url_param jsessionid check_post
>
>This option could work... but it doesn't (for me, at least).  Is the
>config line wrong?  Here's an example HTTP request from our log file:
>
>... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1"
>
>Can/should I just modify the source for url_param matching to look for
>';' instead of '?' as a workaround?

This could not work due to the fact that the jsessionid=... is not part
or query string.

from http://haproxy.1wt.eu/download/1.3/doc/configuration.txt

###
url_param   The URL parameter specified in argument will be looked up in
   the query string of each HTTP GET request.
.
.
###

I think it is not a good idea to change the delimiter from ';' to '?'.

Maybe you will be happy with 'uri' as lb method?

Maybe there should be parameter delimiter or regex for the load
balancing algorithm uri?

E.g.: delimregex ;\\s+jsessionid=([:xdigit:]+) or similar

BR

Aleks

Re: Sticky session, dumb client

[Aleksandar Lazic]

Dear Michael,

On Mon 26.10.2009 21:18, Robinson, Michael wrote:

I've got HAproxy 1.3.22 configured on two EC2 servers in front of two
Apache/Tomcat frontends serving a JSP-based mobile phone application.
The application requires session stickiness - I've tried every
documented alternative HAproxy offers for session persistence,
unfortunately without luck.  The mobile device (well, our application)
does not support cookies and will not echo a modified jsessionid cookie
on subsequent requests.  Two options seem ideal, but there are
roadblocks:

1. appsession jsessionid len 52 timeout 1h

However, since cookies aren't an option, we hoped to leverage
appsession URL lookup... which has the honor of being on the matrix of
all known bugs posted on
10/18 (thanks for posting this, BTW!)

Any ideas if/when this may make it into a stable release?


It should work in the current release of haproxy.
Do you have faced some problems, or bugs?


2. balance url_param jsessionid check_post

This option could work... but it doesn't (for me, at least).  Is the
config line wrong?  Here's an example HTTP request from our log file:

... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1"

Can/should I just modify the source for url_param matching to look for
';' instead of '?' as a workaround?


This could not work due to the fact that the jsessionid=... is not part
or query string.

from http://haproxy.1wt.eu/download/1.3/doc/configuration.txt

###
url_param   The URL parameter specified in argument will be looked up in
  the query string of each HTTP GET request.
.
.
###

I think it is not a good idea to change the delimiter from ';' to '?'.

Maybe you will be happy with 'uri' as lb method?

Maybe there should be parameter delimiter or regex for the load
balancing algorithm uri?

E.g.: delimregex ;\\s+jsessionid=([:xdigit:]+) or similar

BR

Aleks

Re: Sticky session, dumb client

[Cyril Bonté]

Le mardi 27 octobre 2009 02:18:35, Robinson, Michael a écrit :
> I've got HAproxy 1.3.22 configured on two EC2 servers in front of two 
> Apache/Tomcat frontends serving a JSP-based mobile phone application.  

Does 1 apache instance can talk to 1 (and only 1) tomcat or can it talk to both 
tomcat ? How the communication is made between them (mod_jk, 
mod_proxy_ajp/http/balancer) ?


> The application requires session stickiness - I've tried every documented 
> alternative HAproxy offers for session persistence, unfortunately without 
> luck.  The mobile device (well, our application) does not support cookies and 
> will not echo a modified jsessionid cookie on subsequent requests.  Two 
> options seem ideal, but there are roadblocks:
> 
> 
> 1. appsession jsessionid len 52 timeout 1h
> 
> However, since cookies aren't an option, we hoped to leverage appsession URL 
> lookup... which has the honor of being on the matrix of all known 
> bugs posted on 10/18 (thanks for 
> posting this, BTW!)
> 
> Any ideas if/when this may make it into a stable release?

You should try with "len 32" if there's no jvmRoute in the tomcat configuration.

 > 2. balance url_param jsessionid check_post
> 
> This option could work... but it doesn't (for me, at least).  Is the config 
> line wrong?  Here's an example HTTP request from our log file:
> 
> ... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1"
> 
> Can/should I just modify the source for url_param matching to look for ';' 
> instead of '?' as a workaround?

I don't think this will work as the hashed value of jsessionid won't necessarly 
point to the server that provided this session.

-- 
Cyril Bonté