-
Notifications
You must be signed in to change notification settings - Fork 17
Add sticky session support to containous/oxy's round robin #4
Conversation
Sticky sessions are set through an HTTP cookie. If the cookie: * is not present, use the next server & set that as sticky * is present, * but is no longer valid, use the next server & set that as sticky * and valid, use that server without advancing .next.
layer 7, that is... layer 8 is something different (https://en.wikipedia.org/wiki/Layer_8)
Hi @owen, thanks a lot! |
I don't like sticky sessions either. But we have ~100 legacy applications that I don't want to rewrite 😆
There shouldn't be a technical concern, I just haven't decided the best way to handle it -- I think what would be best is for rebalancing to occur for new connections, but for connections that have a cookie we keep the same backend. I'll probably work on that today, actually! |
Great!
Seems good :) |
OK - the logic remains unchanged for new connections; if, however, a cookie is set the connection will be stuck. I'm going to ping the vulcand maintainers to see if they are interested at all as well |
Thanks a lot @owen, great job! |
// make shallow copy of request before chaning anything to avoid side effects | ||
newReq := *req | ||
newReq.URL = url | ||
stuck := false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum, there is an issue here I think.
You don't call url, err := r.NextServer()
if stuck
is false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad I saw your comment in my other PR, I didn't see this comment!
I've retraced the logic of that section. The flow is this:
- Look to see if we have a sticky session
** if so, pull the server out of the cookie and store it.
** if not, fall through to the next session - Look to see if we use sticky sessions & do not have a server || if we do not use sticky sessions:
** call NextServer() to get the approp. URL
** if we have sticky sessions, stick that backend - Return the calculated backend URL
So we only call NextServer() if we have failed to retrieve a server URL from the cookie - that's in the if !stuck {
stanza. We won't call it if stuck = true
, which is only if we have retrieved the server from the cookie -- and, validated that it is still a valid server, which we handle in ss.GetBackend
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@emilevauge let me know if that clears it up! alternatively, if I'm missing something here - which I may be ;) - let me know and I can revise
b3bd8a0
to
b57d670
Compare
d12fc74
to
ab7796d
Compare
Hi @owen, sorry for the delay... We add to wait for traefik 1.0.0 stable before touching oxy ;) |
Hum, there is a minor issue in the test |
That's odd. I'll look at this today!
|
Bonjour @emilevauge,
This change is the same I've pushed through to vulcand/oxy(vulcand#41) - but that hasn't been accepted, so I'll throw it over here!
I've got another PR that depends on this one for Traefik to use it, that will be coming soon...
I've not implemented this PR for the rebalancing round robin since I'm not certain how that will function... any comments are appreciated :)