session
session copied to clipboard
better solution for disconnected store
migrated from https://github.com/senchalabs/connect/issues/973
Is it reasonable to just default to a cookie store for this when another store is unavailable?
(or you could just have it cache it in a temporary memory store, but that seems like a bad idea..)
naw. these sessions could be humongous
Is it reasonable to just default to a cookie store for this when another store is unavailable?
plus if it is unavailable, how would you get the data out of the store to put into the cookie? :)
I experienced undefined req.session every so often caused by a disconnected redis store (using ElastiCache).
Here's a workaround that recreates the session middleware with a new Redis connection when the old connection disconnects.
Not sure if it would make sense to attempt a reconnect in the module itself.
app.use((function(){
var sessionMiddleware;
var createMiddlware = _.throttle(function() {
var store = new RedisStore({ ... });
store.on('disconnect', createMiddlware);
sessionMiddleware = session({
store: store,
cookie: { maxAge: 60000 },
});
}, 2000);
createMiddlware();
return function(req, res, next) {
sessionMiddleware.apply(this, arguments);
};
})());
app.use(function(req, res, next) {
if (req.session) return next();
res.send(500, 'Servers are updating. Please check back soon.');
});
Not sure if it would make sense to attempt a reconnect in the module itself.
It's up to the core to reconnect; the reason this module gives undefined is because you store explicitly told us to do so--a store does not have to do that and just auto-reconnect and you won't experience that, but it's up to the store to do so.
You'll need to report the issue here: https://github.com/visionmedia/connect-redis/issues
the choice of what to do when the store is unavailable is definitely the application's - based on the use case,
- one could wait for a while with timeout, if the store becomes auto-available again,
- one could return an error if the app critically session-sentitive,
- one could behave as if there was no session
but again, the choice is best left to the application, not the middleware.
I guess this can be closed.
This issue seems to be stale, was proposed for closing last year with no objections. Closing now.