RE: http-keep-alive broken?
Hi, Well, after spending some time compiling testing compiling testing I finally found that the patch 0103-OPTIM-MEDIUM-epoll-fuse-active-events-into--1.5-dev19.diff done between 20131115 and 20131116 is causing my problems. I also found that this problem is much easier to reproduce on Safari than on Firefox or Chrome. Ok. Can you try if disabling epoll works around this problem (noepoll in the config or command-line argument -de [1]) to double check it has todo with epoll? The weird thing is that this commit has been reverted in dev21 but I still have the problem in dev21. So I am a bit confused No, dev-21 don't has this revert. dev-21 was released December 16th and the offending commit 2f877304ef (from November 15th) was reverted via commit 3ef5af3dcc on December 20th. But you are using snapshot ss-20131229 which does contain this revert. Does this make any sense to you? Just to be on the safe side: could you download a clean and uptodate snapshot haproxy-ss-20140104 [2], to avoid any missing patches? So in the end, haproxy-ss-20131115 [3] works fine and haproxy-ss-20131116 [4] has this problem, correct? I know this triple checking sucks, but what you are reporting doesn't make sense because, like you said yourself, this was reverted. Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-noepoll [2] http://haproxy.1wt.eu/download/1.5/src/snapshot/haproxy-ss-20140104.tar.gz [3] http://haproxy.1wt.eu/download/1.5/src/snapshot/haproxy-ss-20131115.tar.gz [4] http://haproxy.1wt.eu/download/1.5/src/snapshot/haproxy-ss-20131116.tar.gz
RE: HA-Proxy version 1.5-dev21-51437d2 2013/12/29 sticky ssl sessons are not working in my environment
Hi, My web servers contain text file wich contain name of that server. Then put following line to web browser https://X.X.X.X/index.txt and browse this page it displays server name One server file index.txt contains server name etee-live1 and other server the file contains this server name etee-live2. If affinity works browser displays always the same server name and then in the sticky tabel must contain one entry. But in my SSL affinity case web browser displays once one server name and on the other refresh browser displays other server name . Then i look sticky table it displays two entries but in then SSL affinity - (SSL sticky session) case there must be one entry. My sticky table displys: echo show table etlive_https | socat unix-connect:/var/run/haproxy.stat stdio # table: etlive_https, type: binary, size:30720, used:2 0x17eddd4: key=7D4CD359DDAB9F3F7F976E7A995045670FFF0118FDDB72773165273BE6DA16FA use=0 exp=1778829 server_id=2 0x17ee1d4: key=905273E4AC943682F48106A6BD0486F8FD60F8B80E4860FE7032F7D69DC2 use=0 exp=1783937 server_id=1 That sounds like your apache backend server doesn't actually cache the session. If undestood you correctly you suspect that SSL sessions are changing all the time. What software is responsible changing SSL sessioon ID - browser , Apache web server ?! The Apache backend server (the browsers you mentioned all reuse the SSL session ID by default). Person who configred these apache server ensures that these things are working Please double check with that person that the configuration directives SSLSessionCache [1] and SSLSessionCacheTimeout [2] are properly configured. It looks like Apache by default does not cache at all. Also you can try with Vincent's test tool at [3] whether session resumption is actually done or not. Regards, Lukas [1] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessioncache [2] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessioncachetimeout [3] https://github.com/vincentbernat/rfc5077/blob/master/rfc5077-client.c
RE: http-keep-alive broken?
Hey, On 05.01.2014 17:33, Lukas Tribus wrote: Hi, Well, after spending some time compiling testing compiling testing I finally found that the patch 0103-OPTIM-MEDIUM-epoll-fuse-active-events-into--1.5-dev19.diff done between 20131115 and 20131116 is causing my problems. I also found that this problem is much easier to reproduce on Safari than on Firefox or Chrome. Ok. Can you try if disabling epoll works around this problem (noepoll in the config or command-line argument -de [1]) to double check it has todo with epoll? Disabling epoll doesn't fix it... drat... Tested it with ss-20140104. Could it be that it's a more subtle bug somewhere else? The (reverted) epoll patch and some other patch currently included may make it easier to trigger? The weird thing is that this commit has been reverted in dev21 but I still have the problem in dev21. So I am a bit confused No, dev-21 don't has this revert. dev-21 was released December 16th and the offending commit 2f877304ef (from November 15th) was reverted via commit 3ef5af3dcc on December 20th. Sorry, that's actually what I meant. Just to be on the safe side: could you download a clean and uptodate snapshot haproxy-ss-20140104 [2], to avoid any missing patches? Did that, with and without epoll enabled and it both fails. So in the end, haproxy-ss-20131115 [3] works fine and haproxy-ss-20131116 [4] has this problem, correct? I know this triple checking sucks, but what you are reporting doesn't make sense because, like you said yourself, this was reverted. No problem, check as much as you want. It sucks if I somehow push you guys in the wrong direction. But, Yes, that is correct. 20131115 works and 2013116 doesn't. I tested it a couple of times. The bug is very, very subtle I just found out. When using OSX 10.9 with safari 7 it fails with for instance 20140104 and 20131116 and works with 20131115. But, if I take an older 10.8 machine with safari 6 it works with all versions. I am losing my mind here ;-) I'm pretty sure I saw other platforms/browsers hang in the same way but that was all under load ~150 people accessing there servers during office starting hours. Greets, Sander
RE: http-keep-alive broken?
Hi, Disabling epoll doesn't fix it... drat... Tested it with ss-20140104. Could it be that it's a more subtle bug somewhere else? If disabling epoll doesn't workaround that problem then another patch must be the reason for this. But, Yes, that is correct. 20131115 works and 2013116 doesn't. There is only one single other patch between those 2 snapshots: Commit 38d5892634 (OPTIM/MINOR: mark the source address as already known on accept()). Could it be that you made a off-by-one error when troubleshooting (sorry for suggesting this - but its the only thing I can think of really)? Could you retry with current code and only revert that particular patch? If you use git, then you just: git revert 38d5892634 Otherwise you reverse apply this patch again: patch -p1 -R 0104-OPTIM-MINOR-mark-the-source-address-as-alre-1.5-dev19.diff 0104-OPTIM-MINOR-mark-the-source-address-as-alre-1.5-dev19.diff is in haproxy-1.5-dev19-patches-20131116.tar.gz [1]. If this doesn't help, we probably need to troubleshoot this from another angle, by comparing debug logs of working and non-working situation, but knowing what exact patch introduced the problem is a very valuable information. PS: git is a real lifesaver when you do this kind of troubleshootings. Reverting patches, git bisect to find the patch to blame, you don't need to fiddle with diff files, etc. Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/haproxy-1.5-dev19-patches-20131116.tar.gz
