Hi Pieter and Willy,

Le 01/03/2018 à 16:09, Pieter Vogelaar a écrit :
Hi Willy,

Yes I'm absolutely certain that the cookie is present in the browser request 
when I get the 503.
I changed the JSESSIONID line to "cookie SERVERID insert indirect nocache", but 
that didn't make a difference.

Log line when both servers in backend are in maintenance mode:

172.30.214.130:56887 [01/Mar/2018:15:37:24.928] default-https~ pieter-tomcat-tst/<NOSRV> 
0/-1/-1/-1/0 503 3576 - - SCDN 1/0/0/0/0 0/0 
{tst-pieter.example.org||nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7||Mozilla/5.0 (Macintosh; Intel Mac 
OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36} {|||} 
"GET /hello-world/ HTTP/1.1"

Log line when both servers in backend are active:

172.30.214.130:56451 [01/Mar/2018:15:37:09.734] default-https~ 
pieter-tomcat-tst/pieter-tomcat-01t:8080 0/0/1/2/3 200 5243 - - --VN 2/1/0/0/0 0/0 
{tst-pieter.example.org||nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7||Mozilla/5.0 (Macintosh; 
Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 
Safari/537.36} {text/html;charset=ISO-8859-1|||} "GET /hello-world/ HTTP/1.1"

Well, I think your issue will be resolved by moving "force-persist" on the backend side instead of the frontend one.

The issue seems to exist from the first day of "force-persist", where the code and the documentation don't agree about the sections where it can be used.

From the documentation and the config parser, it can be used in a frontend, but the code only loop on the s->be to evaluate the
persistence options.

See commit http://git.haproxy.org/?p=haproxy.git;a=commit;h=4de9149f876cc0c63495b71a2c7a3aefc722c9c0 for details.

The same issue was also introduced with "ignore-persist".



Best regards,
Pieter Vogelaar
Op 01-03-18 15:32 heeft Willy Tarreau <w...@1wt.eu> geschreven:

     On Thu, Mar 01, 2018 at 02:29:57PM +0000, Pieter Vogelaar wrote:
     > Hi Willy,
     >
     > We use Memcached Session Manager that stores the Tomcat sessions to a Couchbase 
cluster. It suffixes the session ID with "-n1" like:
     >
     > JSESSIONID=s01~1C7985929CDF981D9ACC79EBD8A3293D-n1
     >
     > Could this JSESSIONID format somehow have impact on HAProxy?
No, that's fine, but my point is : are you certain it is present in your
     browser's request when you get the 503 ? If the 3 char of the termination
     flags in the logs indicates '-' or 'N', it means it's absent. Or if you
     can run haproxy in debug mode (with -d), you will see all requests on the
     screen and it will be easy to tell whether the cookie is there or not.
Willy


--
Cyril Bonté

Reply via email to