# New session sent to incorrect backend after soft reload

**URL:** <https://discourse.haproxy.org/t/new-session-sent-to-incorrect-backend-after-soft-reload/490>\
**Category:** Help!\
**Created:** [July 10, 2016, 10:09pm UTC](https://discourse.haproxy.org/t/new-session-sent-to-incorrect-backend-after-soft-reload/490 "2016-07-10T22:09:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![codeslinger](https://avatars.discourse-cdn.com/v4/letter/c/e9a140/32.png) [@codeslinger](https://discourse.haproxy.org/u/codeslinger)\
**Post date:** [July 10, 2016, 10:09pm UTC](https://discourse.haproxy.org/t/new-session-sent-to-incorrect-backend-after-soft-reload/490/1 "2016-07-10T22:09:01Z")

</div>

Hi all,

I have a setup with multiple HAProxy servers (running 1.6.3 from [haproxy.org](http://www.haproxy.org)) balancing for a number of backend servers using `stick-table` to replicate backend target choices between the peers. The sessions coming in are long-lived and need to all hit the same backend for the same logical grouping. (`X-Foobar` header value)

I also have a script that runs periodically to discover the existence of backends and will recreate the `haproxy.cfg` file in the event that any have been added or removed. (for blue/green deploys) It will recreate the config file and then issue a soft reload (`haproxy -sf`).

I’ve noticed, though, that sometimes right after the reload a new session will come in and be sent to a backend that was different than that was chosen prior to the reload. See the logs in this paste (`haproxy.cfg` also in there):

[https://gist.github.com/codeslinger/7c631fd18b30c41b57a23e949cf12d58](https://gist.github.com/codeslinger/7c631fd18b30c41b57a23e949cf12d58)

Note in the `haproxy.log` section therein that the connection that came in at `21:27:11` was placed on a different backend than the one that came in at `20:59:10`, even though they had the same `X-Foobar` header value. The reload occurred at `21:27:03`. There were other sessions with this same `X-Foobar` value that came in before the reload on all the peer HAProxys that also were directed to the correct backend. I imagine that means the record was in the sticktable and replicated properly prior to the reload, no?

My guess is that there is a race condition whereby the new process attaches to the listening ports and starts servicing new sessions prior to receiving any/all of the sticktable data from the old process. I’ve confirmed in the source code that the listening ports are bound in the new process before the `SIGUSR1` is issued to the old process to tell it to stop service, but I can’t seem to find where the sticktable data is sent to the new process quite yet. (i.e. no smoking gun for a bug report)

Does anyone have any ideas on how I can fix/workaround this issue? Given the nature of our sessions, if they don’t all hit the same backend, its a really bad experience for our clients. I would sure appreciate any help anyone had to give. Thanks!

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [July 12, 2016, 12:05pm UTC](https://discourse.haproxy.org/t/new-session-sent-to-incorrect-backend-after-soft-reload/490/2 "2016-07-12T12:05:11Z")

</div>

I suggest you post this one on the mailing list (more eyes), just send an email to:

> [haproxy@formilux.org](mailto:haproxy@formilux.org)

You don’t have to subscribe, just send the email there.