Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Sticky Sessions #147

Closed
bendytree opened this Issue · 2 comments

2 participants

@bendytree

First off - huge fan of Primus. It literally saved me from a socket.io disaster back in August.

The readme says that scaling requires your load balancer to support sticky sessions.

As far as I can tell, Modulus, Heroku, and ELB don't support sticky sessions.

Would someone mind explaining why Primus needs sticky sessions? Is there a work-around?

@3rd-Eden 3rd-Eden added the discussion label
@3rd-Eden
Owner

Not every transformer requires sticky sessions in order to work across multiple connections, the only notable exception for this can be the WebSockets transformer as it just creates one single connection to the server and when that connection closes, the whole session ended.

The other transformers use polling transports like XHR and JSONP polling in order to communicate with the server. The server uses a bunch of timeouts to keep the session alive on the server alive so the client can initialise a new request and transfer more data. This session is only stored in the Node process that received the initial connection (which is usually the handshake that these frameworks make). So if the request goes to a different node process it will not know how to handle the request and discard it causing message loss and eventually timeout connections as the session on the server that received the initial connection timed out. With sticky load balancing the requests that the client make will continue to go to the node process that accepted the initial connection and everything will work as expected.

Some transformers like Socket.IO tried to work around this limitation by introducing a RedisStore which would replicate all connection data between every single connected node instance. Which will ultimatley result in a complete cluster fuckup (there are other failures as well, but that's not really important here). So isn't really an option either.

@bendytree

Thank you - I really appreciate the explanation.

@bendytree bendytree closed this
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
419d046
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
df9bf76
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
a385daf
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
c2a16ae
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
06da474
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
fb23fd9
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
ce038ed
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
e0a4c3d
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
7e2b62b
@wenzowski wenzowski referenced this issue from a commit in dialoghq/deis
@wenzowski wenzowski feat(router): add optional query string affinity support
To be enabled with extreme prejudice. Twelve-factor processes should be
stateless and share-nothing. Sticky sessions should not be used to cache
user data in memory. Use a backing store to persist session state.

Valid uses, however, do exist and are widespread: eg. see primus/primus#147

> HTTP implementations are expected to engage in connection management,
> which includes maintaining the state of current connections,
> establishing a new connection or reusing an existing connection,
> processing messages received on a connection, detecting connection
> failures, and closing each connection.
> <cite>[RFC 7230]</cite>

Many real time systems rely on detection of connection failures at the
application level. Without session affinity, detection of connection
failures stops at the load balancer and causes undesirable side-effects
for many implementations. For instance, the Google BrowserChannel implementation
that may have led @zag2art to #2060 relies on detection of connection
failures, as does socket.io

Care should be taken when using this setting in conjunction with a 3rd party
Layer-7 load balancer. At this time, Amazon's ELB and Rackspace's Cloud Load
Balancer, for instance, only support cookie-based affinity which must be
manually enabled. Many OSI Layer-4 load balancers, such as the Azure Load
Balancer and GCE Network Load Balancing, currently perform [RFC 2474] 5-tuple
"microflow" hashing by default.

[RFC 2474]: https://tools.ietf.org/html/rfc2474
[RFC 7230]: https://tools.ietf.org/html/rfc7230
92a5549
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.