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é