Open 0o-de-lally opened 7 years ago
Looks like 1.3.5 is causing instability in one of my Meteor.call() methods, and the queue callback() is not completing.
Described here. https://github.com/vsivsi/meteor-job-collection/issues/158
I will close for now.
@vsivsi Should I expect the job server to restart after mongodb is reconnected? I also notice that even if I clear the DB from stuck jobs, the job server isn't responding to new tasks. I must restart the server. Any advice?
What precisely do you mean by "restart"? Like any functionality built on top of a database, a jobCollection will generate errors when the database isn't accessible. Assuming Meteor itself does reasonable things when MongoDB shifts from being online to offline and then back online, jobCollection shouldn't need to be "restarted" in any special way, assuming your application has been been gracefully handling any errors generated (thrown or returned in callbacks) while the database was down. You could choose to shutdown and restart the job server as a part of your application error handling logic, but neither shutdown nor the restart are automatic. Hope that helps.
This is a tricky one to offer a reproduction for.
I'm noticing that after a mongo DB crash, when meteor eventually reconnects to the db, the job server is no longer running. I would expect it to connect again, and I think previous to meteor 1.3.5 it had.
I could handle this myself, but I don't know how to check if the server is running. It would be nice to have an jc.isRunning() method, so we could use as such.
Tracker.autorun(function(){ if ( QUEUE.isRunning() ) { Meteor.call("OMG_SomethingIsWrong_startTheJobServer") }
});