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 <a...@davz.net> 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.
