Hi Alex, Actually, I suspect your issue to be related to the stick table synchronisation mechanism. I'll talk to Emeric and Willy tomorrow about it.
Baptiste On Wed, Mar 20, 2013 at 12:42 PM, Alex Davies <[email protected]> wrote: > For those interested, this turned out to be some wierdness in haproxy - one > of the servers was only storing the first 24 (despite being configured for > 32, and the other identical binary/config working fine). > > The way to debug was the following on both servers for a given cookie value: > > echo show table webservers | socat /var/lib/haproxy/stats - | fgrep > 4start_of_session > > From my config, it was also important to store text not binary data in the > table. > > -Alex > > > On Sat, Mar 2, 2013 at 5:32 PM, Alex Davies <[email protected]> wrote: >> >> I was trying to troubleshoot this with a packet dump on the "peer" >> traffic. The raw tcpdump does not mean anything to me, and Wireshark is >> decoding it as Java RMI traffic which isnt much use, and it looks like a >> binary protocol. >> >> So I can report that 'peer' traffic is certainly working because when I >> restart one of the haproxy processes there are a bunch of different packets >> sent (Wireshark doesent even attempt to decode these). I was hoping to be >> able to grep for one of the offending session IDs to see if that gave me a >> hint. >> >> Does anybody have a working configuration for multi peer persistence based >> on a cookie that I could test, by chance? >> >> Thanks, >> >> -Alex > > > > > -- > Alex Davies > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the sender immediately by e-mail and delete this e-mail permanently.
