Mojito service shuts down after critical error #699

ItsAsbreuk opened this Issue Nov 2, 2012 · 9 comments

2 participants


I've got an examplecode shown in
Now, the problem arises at line 84: if there is a MySql-error, this.end() is called, but this function does not exists. Reason is problably because 'this' is not the anonymous function mysqlClient.createClient, but mysqlClient.createClient.query.

There are 2 things in this:

1st. The Mojito service will throw an error and ends completely. So the Mojito service isn't running anymore and nobody can make requests until Mojito is restarted. This is very bad for productionpurposes. Better to respond a HTTP status-code 500 error and keep Mojito running.

2nd. I would be thankful if you could show me how the code should be: how I end the mysqlClient.createClient in a proper way.

(Using Mojito 0.4.8)



Marco, I'm not so sure I understand what you ask for. In your code, it is your responsibility to control the flow, and eventually call ac.done or ac.error.

About production, obviously you don't want a node process to crash, but if that happen, your container (hosting infrastructure for node) should be able to restart the process automatically. Most container out there are doing that.


Hey Caridy,

All right, I see I need some adjustments to restart Mojito if it shuts down...

I know its my responsibility. to control the flow.
Fact is that in the Model, I execute MySql. When an error occurs, it is catched and the Model will return an error to the controller, which calls ac.error. Everything fine here.

But, I experienced the situation that during reading mysql in the model, all crashed. That seems strange to me. Taking a deeper look, I found that Mojito does handle functioncalls that don't excists. Say client.abcd(); will result in a red lines in the console like this:

Error executing child mojit at 'firmselection':
ERROR mojito-composite-addon: Object # has no method 'abcd'
ERROR mojito-composite-addon: TypeError: Object # has no method 'abcd'
at Object.getData (/var/www/mojito-sites/heidata_nl/mojits/FirmSelection/models/foundationfactories.server.js:44:8)
at Object.index (/var/www/mojito-sites/heidata_nl/mojits/FirmSelection/controller.server.js:28:61)
at new ActionContext (/usr/lib/node_modules/mojito/lib/app/autoload/action-context.common.js:323:34)
at Object.invoke (/usr/lib/node_modules/mojito/lib/app/autoload/controller-context.common.js:141:22)
at /usr/lib/node_modules/mojito/lib/app/autoload/dispatch.common.js:192:28
at [object Object]._notify (/usr/lib/node_modules/mojito/node_modules/yui/yui-nodejs/yui-nodejs.js:836:17)
at /usr/lib/node_modules/mojito/node_modules/yui/yui-nodejs/yui-nodejs.js:817:19
at [object Object]._notify (/usr/lib/node_modules/mojito/node_modules/yui/yui-nodejs/yui-nodejs.js:836:17)
at [object Object]. (/usr/lib/node_modules/mojito/node_modules/yui/yui-nodejs/yui-nodejs.js:971:27)
at Object._finish (/usr/lib/node_modules/mojito/node_modules/yui/yui-nodejs/yui-nodejs.js:6432:19)

But Mojito stays alive nevertheless.

Now, calling this.end(); leads to:

TypeError: Object # has no method 'end'
at selectCb (/var/www/mojito-sites/heidata_nl/mojits/FirmSelection/models/foundationfactories.server.js:51:6)
at Query. (/usr/lib/node_modules/mysql/lib/client.js:95:9)
at Query.emit (events.js:67:17)
at Query._handlePacket (/usr/lib/node_modules/mysql/lib/query.js:33:12)
at Client._handlePacket (/usr/lib/node_modules/mysql/lib/client.js:319:14)
at Parser. (native)
at Parser.emit (events.js:67:17)
at /usr/lib/node_modules/mysql/lib/parser.js:71:14
at Parser.write (/usr/lib/node_modules/mysql/lib/parser.js:576:7)
at Socket. (native)

And Mojito stops.
Of coarse you can say it's my fault: I shouldn't call this.end(); But I rather have seen a red lines..

It's not that I think you need to change this no matter what. I just mention it helping you guys making Mojito better.



I ran into it again, but in a different situation now: using an own YUI-module.

So, let me explain it better:

Situation 1 goes all right:
If I make a functioncall that refers to a mojio-object with a undefined function (for instance ac.models.MyModelFoo.undefinedFunc()) then Mojito nicely returns a http status 500

Situation 2 goes wrong:
If I make a functioncall that refers to an external module (for instance an own designed YUI-Module) where the module does exists, but I call an undefined function (for instance Y.MyCorrectWidget.undefinedFunc()) then Mojito crashes without further calling ac.error() (and thus without response).



Caridy, rethinking this issue, made me realize very unpleasant things might happen.

In my situation I was lucky because Mojito just stopped. You -on the other hand- run on your own hosting infrastructure (Manhattan?) that will restart after such a situation.

So, what happens if you make a typo on an external module? Your Mojito-service might have multiple threads waiting for their callback. But at the time the typo tries to execute, the service stops, all callbacks are never being returned and the Mojito service will restart.

So: you wander why you missed your specific callback that actually has no error itself. You probably reload the page, which will succeed, because Mojito is restarted. You retry to execute your valid functioncall (not the one with the typo) and this time you get your callback. Try to debug/profile this... You will be looking at the wrong place.

I don't have all the insight in Mojito, so I hope It's not that bad as i think.



The same with this situation:

Situation 1:
In the regular Mojito-code:
var item = myArray[i] // <-- where i is undefined
Mojito throws error 500 and continues running

Situation 2:
Within a callback of an external module:
var item = myArray[i] // <-- where i is undefined
Mojito-service stops completely:
item = myArray[i];
ReferenceError: i is not defined
at selectCb (/var/www/mojito-sites/heidata_nl/mojits/ProjectData/models/project.server.js:53:41)
at Query. (/usr/lib/node_modules/mysql/lib/client.js:108:11)
at Query.emit (events.js:64:17)
at Query._handlePacket (/usr/lib/node_modules/mysql/lib/query.js:51:14)
at Client._handlePacket (/usr/lib/node_modules/mysql/lib/client.js:319:14)
at Parser. (native)
at Parser.emit (events.js:67:17)
at /usr/lib/node_modules/mysql/lib/parser.js:71:14
at Parser.write (/usr/lib/node_modules/mysql/lib/parser.js:576:7)
at Socket. (native)

So it seems there has to be made a sort of try/catch system when calling external references.



@ItsAsbreuk this is not mojito, but javascript. Basically, if you have something like this:

    function foo () {
        try {
        } catch(e) {
            Y.log('to something about this error');

the try will catch any error during the execution of bar function, but if bar happens to do some asynchronous operation, for example using to load something and then execute a callback, errors within that callback will NOT be caught by the try/catch statement because that routine is done already.

So, in other words, you have to handle those cases where you have an async routine, by adding another try/catch or if statements when posible since the try statement will have some performance penalties as well.


All right, nice to know.

But still, even it's impossible to catch these, does Mojito really needs to crash then?
I mean, ac.models.MyModelFoo.undefinedFunc() returns nicely a 500-error, while still running.
Why cannot this be done when Y.MyCorrectWidget.undefinedFunc() is called?

Like said: one fault-routine can stop running-callbacks of correct working routines. When working in teams I can imagine someone who makes a programming-mistake drives others crazy when they start missing their callback on occasion.

Very unsatisfied situation here...


Better error control will be introduced in 0.6, stay tunned.


mojito-next (0.9.0) allow you to use the regular process in express to control 500 errors.

@caridy caridy closed this Mar 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment