diversario / connect-mongostore Goto Github PK
View Code? Open in Web Editor NEWMongoDB session store for Connect/Express.
MongoDB session store for Connect/Express.
I have configured MongoStore to connect to a replica set. It seems to connect just fine, but whenever I try to access my site, the requests simply time out. There must be an issue with replica set configuration or handling, because simply connecting to a single localhost DB works fine.
I am trying to connect to a MongoHQ replica set. I have provided the username, password, db.name, db.servers, db.replicaSetOptions (with rs_name and w:1).
Am I missing something, perhaps?
I have configured MongoStore to connect to a replica set, the connection is successful and I can see session being added in the sessions collection. But when I try to modify the session object, the update fails and the session does not modify. The collection.update in the set gives RangeError: Maximum call stack size exceeded error.
Am I configuring it wrong?
PS: It is express 3.x and mongoose environment.
I'm using a MongoHQ(Compose) replica set and am having issues using that existing mongoose connection with the mongostore, is there additional configuration I'm missing?
While working on a local machine (very low latency) between frontend and backend, I had the following rare case:
When the ".set" gets called, there is some time between submitting the save (upsert) request to the database and between getting the callback that the data is actually updated. Between this short period of time, there is a chance to get a dirty read from a new concurrent request.
I think this should solve it: When .set is called, the session object for the specific sid should be left in memory temporarily, if a get request is triggered then, that get request should return this temporary session in memory and not read from db. When the callback of the .set is called and the actual data is updated to the database at that point you can get rid of the temporary session object that you left in memory, so subsequent .get calls will fetch again from database now...
Of course there are cases where you get subsequent saves (.set) some sort of reference counting on the temp session object in memory should resolve this. The problem doesn't stop here but this solves part of it. Two concurrent calls will start with two .get, each receiving a different copy in memory, at this point one of the two will finish first and will save the new updated session object, when the next calls is also done and wants to save it's copy, the first ones save is lost...
Furthermore you should add some defense mechanism to the .save. The session object read should have the last timestamp when the data in Mongo was updated. Upon saving, that timestamp to be saved should be the same with the timestamp that is already there, (add to filter, if they don't match, update count = 0) otherwise, in between a newer session state was saved from a different source. Not sure how to react in this situation, but at least we shouldn't overwrite the session data in this case as a probably newer version already is there in the database. In RDB environments, ideally, the database takes care of this concurrency problem.
Thank you.
http://docs.mongodb.org/manual/reference/connection-string/ - the connection string can have multiple hosts. Any chance to support these?
Is there any way to indicate the authSource for the connection settings?
http://docs.mongodb.org/manual/reference/connection-string/#authentication-options
I've tried setting it in the replica set options with no luck. Any ideas?
I do have a replica set in production, so I decided it would be better to use this module, and I thought maybe this issue would disappear if I pass it the mongoose connection, instead of trying to spawn a new connection to the database, but alas, I am still seeing this get thrown on livereload trigger of app restart:
Error: Error getting collection: sessions <Error: Error setting TTL index on collection : sessions <Error: Error setting TTL index on collection : sessions <Error: Cannot determine state of server>>>
at /Users/davis/git/warehouse-web/node_modules/connect-mongostore/lib/connect-mongostore.js:110:22
at Db.collection (/Users/davis/git/warehouse-web/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:534:27)
at MongoStore.getCollection (/Users/davis/git/warehouse-web/node_modules/connect-mongostore/lib/connect-mongostore.js:109:13)
at MongoStore.get (/Users/davis/git/warehouse-web/node_modules/connect-mongostore/lib/connect-mongostore.js:133:10)
at session (/Users/davis/git/warehouse-web/node_modules/express-session/index.js:355:11)
at Layer.handle [as handle_request] (/Users/davis/git/warehouse-web/node_modules/express/lib/router/layer.js:82:5)
at trim_prefix (/Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:270:13)
at /Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:237:9
at Function.proto.process_params (/Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:312:12)
at /Users/davis/git/warehouse-web/node_modules/express/lib/router/index.js:228:12
Here's what I'm doing -- please tell me if there is a recommended way to resolve this:
in app.js
mongoose.connect(config.mongo.uri, config.mongo.options);
var app = express();
mongoos.connection.on('connected', function () {
debug('mongoose connected to %s, mongoose.connection.readyState %d', config.mongo.uri, mongoose.connection.readyState);
// other modules are required here like mongoose models
// this require is now delayed until supposedly mongoose is in ready state
require('./routes/express')(app);
});
mongoose.connection.on('error', function (err) { console.error('mongoose connection error ', err); });
in ./routes/express.js (required from above)
var session = require('express-session'),
MongoStore = require('connect-mongostore')(session)
module.exports = function (app) {
// other code setup up cookie parser, body parser, etc.
app.use(session({
secret: secret,
saveUninitialized: true,
resave: true,
store: new MongoStore({
mongooseConnection: mongoose.connections[0],
collection: 'session',
auto_reconnect: true
}, function () {
debug('express connect-mongostore session store connected.');
}));
My localhost dev machine does not have a replica set -- not that it matters much for this issue. The problem happens when livereload triggers a server reload. I'm using gulp-livereload, and when it detects a file has been saved in the server source, it will respawn the app.
// have nodemon start the express server; nodemon only restarts on change in src/server
gulp.task('nodemon', function () {
plugins.nodemon({
script: './src/server/bin/www',
verbose: true,
env: {
'NODE_ENV': 'development',
'DEBUG': '* -express:* -send -session -mquery -express-session'
},
watch: './src/server',
ext: 'js jade html css styl json',
nodeArgs: ['--debug']
}).on('restart', function () {
// initiate livereload -- sometimes happens too fast; 500 ms was too short for me
setTimeout(function () {
log('Trying to refresh livereload after server has restarted...');
reload.changed('/');
}, 1000);
});
});
Starting this trivial static file sever:
var express = require('express'),
app = express(),
http = require('http'),
server = http.createServer(app)
;
var morgan = require('morgan');
app.use(morgan('dev')); //this is the express logger...
app.use(require('errorhandler')({dumpExceptions: true, showStack: true}));
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// HERE comes the problem:
var session = require('express-session');
var MongoHttpSessionStore = require('connect-mongostore')(session);
var cookieParser = require('cookie-parser');
app.use(cookieParser());
app.use(session({
secret: "x",
store: new MongoHttpSessionStore(
{
collection: "_sTEST_delete",
db: "test"
}
),
cookie: {
maxAge: 60000 * 30
}, // in minute(s) from milliseconds-> *60000
// the following are both default true
resave: true,
saveUninitialized: true
}
));
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
app.use('/', express.static(__dirname + '/public')); //at last try to find if this is a static file...
server.listen(3005);
console.log("started on port 3005");
and testing it with apache bench
ab -c 1 -n 2 -k http://localhost:3005/test.html
leads to the Problem that the second request is never being answered.
If issuing manual several test with
ab -c 1 -n 1 -k http://localhost:3005/test.html
every thing is ok.
Using a memory store session by commenting out the "store" property works also OK even with:
ab -c 10 -n 10000 -k http://localhost:3005/test.html
I came to this striped down example from a much bigger one, where I have the problem that "sometimes" request do not get answered and time out...
Any ideas?
Thanks
Ognian
Right it's using the node.js url
module to parse it, with works for single hosts but doesn't work with replica sets.
Some Examples:
I'd suggest either using mongodb's url_parser or muri
What do you think?
When an express instance using connect-mongostore is accessed for the first time, and there are multiple concurrent requests to that server, connect-mongostore will fail with an error. If I wait a while after the initial error, the server seems to run fine. Also, no problems will occur if the first request is allowed to be processed fully before new requests come in.
I suspect that while connect-mongostore is creating the MongoDB connection, the state of the mongostore code is such that requests coming in while the connection is being made will fail.
The error is:
Error: Error setting TTL index on collection : sessions2 <Error: Error setting TTL index on collection : sessions2 <Error: No replica set primary available for query with ReadPreference PRIMARY>>
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:115:24
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1436:28
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1558:28
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/cursor.js:160:22
at Cursor.nextObject (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/cursor.js:733:16)
at Cursor.toArray (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/cursor.js:159:10)
at Cursor.toArray (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/scope.js:10:20)
at Db.indexInformation (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1557:63)
at Db.ensureIndex (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:1435:8)
at Collection.ensureIndex (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/collection/index.js:65:11)
at /home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:114:23
at Db.collection (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/node_modules/mongodb/lib/mongodb/db.js:502:44)
at MongoStore.getCollection (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:109:13)
at MongoStore.get (/home/v2/git/spatineo-monitor/node_modules/connect-mongostore/lib/connect-mongostore.js:133:10)
at Object.session as handle
...
I'm using a three member replica set and express (3.x).
Hi,
I am building an admin GUI to load all sessions by querying to MongoDB directly using mongoose.
'use strict';
var mongoose = require('mongoose');
var Schema = mongoose.Schema;
var SessionModelConfiguration = new Schema({
session: {
cookie: {
path: String,
_expires: String,
originalMaxAge: String,
httpOnly: String,
secure: String,
expires: String,
maxAge: String,
data: {
originalMaxAge: String,
expires: String,
secure: String,
httpOnly: String,
domain: String,
path: String
}
},
passwordless: String
},
expires: String
});
var Sessions_db = require('../configuration/database').Sessions_Access;
module.exports = Sessions_db.model('sessions', SessionModelConfiguration);
var tempList_Session = [];
Sessions_db.find(function(err, models_Sessions) {
for (var i = 0; i < models_Sessions.length; i++) {
tempList_Session.push({
id: models_Sessions[i]._id,
cookie: models_Sessions[i].session.cookie,
User: models_Sessions[i].session.passwordless,
expires: models_Sessions[i].expires
});
}
res.render('User/index', {
tempList_Session: tempList_Session
});
})
Query : I cannot load ._id
but yes i can load all other attributes. Please help
When I click on the link, there's nothing at the other end of it.
The ssl:true option does not appear to work with replica sets. Is this a bug or is there a special/different configuration option that should be used when a replica set configuration is required?
new MongoStore(
{db:'dev', host:'127.0.0.1'},
function(err){
console.log(err || 'connect-mongodb setup ok');
})
I'm not using replica server. Just plain mongo on a single server.
How do I give the auto reconnect option here ?
new MongoStore(
{
db:'dev',
host:'127.0.0.1',
options:{
autoReconnect: true
}},
function(err){
console.log(err || 'connect-mongodb setup ok');
})
Should suffice ??
In a typical mongo connection string one only needs to list a couple servers as seed, and the full replica set configuration is discovered.
Specifically mongohq gives you a recommended connection string with 2 servers, but the replication set that's configured has 1 master, 2 primary and an arbiter.
If I set the server array property in the connect-mongostore config object to list the two servers in the monghq connection string, does it discover the full replication set since it's built on top of the mongo driver?
Because it's not 0%.
We are running on Amazon. The load balancer sends a test to the servers every 15 seconds to make sure the app is alive. We have coded an API call for it to check, which tests if both node and mongo are working. However, this creates a session, with each call, as it's not a web browser, so a new session gets built. We have 80,000 records in our session database, that expire every four weeks. Wondering if there is any way to prevent this happening.
If you upgrade to connect 3.0+, you'll see the tests no longer pass. I imagine that indicates the reason that I can't get this library to run under connect 3.0 with the README's instructions either.
If I use MongoStore(opts,cb) the cb is never called. Doesn't look like there is code to trigger the callback.
I'm trying to see what will happen when the database server goes away. I have configured the socketOptions with timeout for various numbers. I have set it to 10, and 10,000, and I have rebooted my Mongo servers. It sits for longer than 10 seconds, quite a bit longer. Any idea on why this would be so, and what I would need to do to get it to timeout? I'm hoping this never happens, but I'd like to be prepared.
This is what I have now:
"options":{"autoReconnect":true,"socketOptions":{"connectTimeoutMS":10000,"socketTimeoutMS":10000,"keepAlive":1,"encoding":"utf8"}}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.