how to prevent unexpected data from causing fatal crash of nodejs server? - javascript

Despite my extensive experience with nginx, apache, jboss etc. servers, I am very new to nodejs server (It took my interest for socket.io features). I find it strange that unexpected data like say object.MyProperty (which is undefined) etc - which are trivial in my opinion, cause the entire server to crash (it doesnt crash for that client request, but the entire server crashes!) and you need to restart the server.
I am not sure if it is because I am on development mode or it will be like that on live mode as well. When it crashes, all runtime data get lost.
My question is that what should I do make sure that the server doesnt crash but it can write issues to the log file like in other servers.
Any assistance is much appreciated.

You can use try catch blocks for this. And log them under catch.
Updated:
Also, Node being single process based, uncaught exceptions leads to crash (of that process). One of the methods suggested is to use domains.
Example:
domain = require('domain'),
d = domain.create();
d.on('error', function(err) {
console.error(err);
});
d.run(function() {
...
Ref. is a good article and explains in short various approaches to handle the problem.

process.on('uncaughtException', function (err) {
console.error((new Date).toUTCString() + ' uncaughtException:', err.message)
console.error(err.stack)
})
Since nodejs is a single process server, you can place this code anywhere in js script for this to act as a catch all for unhandled/unforeseen errors.

I think you are looking for https://github.com/foreverjs/forever. Forever runs a script forever and restarts it in the event of a crash without user intervention.
You can install forever using npm. Once installed, you can run your nodejs scripts using forever start <path/to/script>. forever list will list all the currently running scripts and forever stop <script-id> will stop a given script.
Keep in mind that using this doesn't mean you don't have to do proper exception handling. Implement try...catch statements as needed and handle all exceptions in code.

The best way to do this would be for you to validate all your incoming post request bodies using a json schema validator. There are several available that are really fast and will add very minimal overhead (less than 1 ms) to your overall response time. I'm the author of one such validator called Themis which we use for REST APIs. There's also a comprehensive benchmark which compares all the available JSON schema validators.
This would prevent your sever from crashing and becoming unavailable simply because of a bad request.

Related

What could cause Electron to not show any errors?

I have taken over an Electron project from another developer.
The problem I am facing is that the project does not show any errors. Even including something like throw "this is an error" does not produce any output on the main process or render process consoles or any sort of standard error popup.
I have checked to confirm that electron-unhandled is not in use and that nothing registers 'uncaughtException'.
What am I missing that could cause this behavior?
Search for: unhandledRejection
unhandledRejection : This will catch any thrown errors, or non fatal errors you have successfully handled via throw.
uncaughtException : This only catches fatal errors or errors that would crash your node instance
WebWorkers : There will be yet another console for webworkers if your using those.
package.json : Take a look in here at the script executed to start electron or however your starting it... Make sure the console is not being sent to a remote console. This feature would allow for debugging the application via Chrome/Firefox vs the standard console. Pretty common for electron apps. If is done via the startup command.
May look something like this:
process.on('unhandledRejection', function (err) {
});
Also, make sure you include any modules in your searching for suppressors as the issue may exist somewhere in the node_modules directory and many IDE's (mine does by default) exclude that directory in indexing/searches.
Another possible reason could be stdout and/or stderr redirection, the problem is this could be achieved by several ways so it's hard to suggest you what to check...
If there is some child_process call to launch a sub-process you could check the stdio array used, or you can check if some low level operation is performed against file descriptors 1 and 2...
Hope this helps.
Are you facing the problem as mentioned in this official thread. You may disable the original event listeners and manage the ELECTRON_BROWSER_WINDOW_ALERT event by my event listener.
Here is the solution
ipcMain.removeAllListeners("ELECTRON_BROWSER_WINDOW_ALERT")
ipcMain.on("ELECTRON_BROWSER_WINDOW_ALERT", (event, message, title)=>{
console.warn(`[Alert] ** ${title} ** ${message}`)
event.returnValue = 0 // **IMPORTANT!**
})

Force a service worker caching to fail for testing purposes

I'm working with my QA team to try and test some new error handling we added to our service worker when it tries to cache some of our JS bundles and I'm looking for a way to cause either one of the cache methods to fail (cache.add, cache.open, cache.match, etc.)
We'd like to be able to test this without changing any code, so, ideally, I would love to find a way to block cache requests in the same way that you can block HTTP requests (or something similar).
Any help is appreciated!
I figured it out (at least in Chrome)!
In the Chrome console at the top left you can select the context in which the console is running and one of the options is the service worker.
Once you are in there, you can over write the cache functions however you want. For my purposes, I just did self.caches.open = () => Promise.reject("Error").

How should I run NodeJS from a Java application?

I'm writing a Java library, actually, a Clojure library, but for this question, what matters is that it runs on the JVM. This library needs to execute some JavaScript. I tried with Nashorn but I encounter some limitations that might be too hard to overcome. As an alternative, I want to try NodeJS.
I want my library to be self contained, to not depend on the system running NodeJS independently and thus requiring a particular deployment mechanism to place the Java and NodeJS artifacts in the right places to be picked up by the two different network servers. This approach, though, brings some issues.
I will be talking to NodeJS over HTTP but I don't want NodeJS to open a specific port. I want to find a random unused one so there's no collisions. I also want to control where the logs from NodeJS go, as to keep them with the rest of my application. Lastly, my app should be able to detect when NodeJS crashed and re-run it or report an error with information.
What's the best way to approach this? Are there any Java libraries to help manage child process in this fashion? Anything in particular I should do from the NodeJS side (I'm very new to NodeJS, I never used it before).
My solution in the end was to use ProcessBuilder like this:
(defn create-process-builder [js-engine]
(doto (ProcessBuilder. ["node" (:path js-engine)
"--port-file" (:port-file js-engine)
"--default-ajax-host" (:default-ajax-host js-engine)
"--default-ajax-port" (str (:default-ajax-port js-engine))])
.inheritIO))
and then call start in it. inheritIO causes the output of it to go to the output of the current process which effectively merges stdout and stderr.
On top of that NodeJS opens a random port by specifying 0 as the port number and writes it to a file:
(let [app (-> (express)
(.use (cookie-parser))
(.get "/" (fn [_req res] (.send res "Universal JavaScript engine for server side pre-rendering single page applications.")))
(.get "/render" render))
server (.createServer http app)]
(.listen server 0 (fn [] (.writeFile fs (:port-file options) (.-port (.address server)))))))))
which then is opened by the Java side (waiting for it to appear):
(defn get-port-number [js-engine]
(or (with-timeout
(:start-timeout js-engine)
(loop [port-number (read-port-file js-engine)]
(if (string/blank? port-number)
(if (is-running? js-engine)
(do (Thread/sleep 100)
(recur (read-port-file js-engine)))
(throw (Exception. (str "While waiting for port number, process died: " (:path js-engine)))))
port-number)))
(throw (Exception. (str "Waited for " (:start-timeout js-engine) " for " (:path js-engine) " to start and report its port number but it timed out.")))))
There is a pretty good answer here on how to run javascript in java. Would something like that be doable for your case? If not here are some resources:
Random port in nodejs You could hit yet another service to find an open port during the build, or have your node app fire an http request to your java server based on the port it grabs.
Winston is the best logging library I've found, you shouldn't have any issues logging to the same path.
Forever and PM2 are the common node process managers which keep node running. I currently prefer forever (not sure why)
It sounds like you will be using a lot of cpu within node. If that is the case you will probably want to use the cluster module (so nodejs can utilize multiple cores). If you block the event loop (which cpu based processing will, then you will only be able to perform 1 concurrent request per forked process).
I have been in a similar position where I had to run fortran from a python script, so here is my two cents. Run your node.js script with a terminal command in Java like this:
Runtime rt = Runtime.getRuntime();
String[] commands = {"node example.js", "args"};
Process proc = rt.exec(commands);
BufferedReader stdInput = new BufferedReader(new
InputStreamReader(proc.getInputStream()));
BufferedReader stdError = new BufferedReader(new
InputStreamReader(proc.getErrorStream()));
// read the output from the command
System.out.println("Here is the standard output of the command:\n");
String s = null;
while ((s = stdInput.readLine()) != null) {
System.out.println(s);
}
// read any errors from the attempted command
System.out.println("Here is the standard error of the command (if any):\n");
while ((s = stdError.readLine()) != null) {
System.out.println(s);
}
With setup you can pass in parameters to your node program and get responses. Although I am not sure what you are using your node.js program for, so not sure if this is helpful.
Nashorn does have some issues that I've run into as well, such as finding information about some of their APIs (documentation leaves a lot to be desired), and the slow boot up.
What I would recommend instead: treat your server-side rendering as a service and not a child process.
In other words, you could run a Node.js instance on your internal net on say port 10015 and only allow local connections to it (you could also send logs wherever you want). Then you can make a request to the service with the pages that you want to render, such as localhost:10015/posts/ and have that Node.js app render the page inside of a headless browser (using something like Phantom or Slimer).
To keep your Node server up, you can use Forever or supervisord, and to help you gain traction faster, you could look at what the Prerender team has made:
https://github.com/prerender/prerender-node

how do you allow javascript communications with Flex/Flash/Actionscript

Well here's a problem.
I've got a website with large javascript backend. This backend talks to a server over a socket with a socket bridge using http://blog.deconcept.com/swfobject/
The socket "bridge" is a Flex/Flash .swf application/executable/plugin/thing for which the source is missing.
I've got to change it.
More facts:
file appExePluginThing.swf
appExePluginThing.swf Macromedia Flash data (compressed), version 9
I've used https://www.free-decompiler.com/flash/ to decompile the .swf file and I think I've sorted out what's the original code vs the libraries and things Flash/Flex built into it.
I've used FDT (the free version) to rebuild the decompiled code into MYappExePluginThing.swf so I can run it with the javascript code and see what happens.
I'm here because what happens isn't good. Basically, my javascript code (MYjavascript.js) gets to the point where it does
window.log("init()");
var so = new SWFObject("flash/MYappExePluginThing.swf"", socketObjectId, "0", "0", "9", "#FFFFFF");
window.log("init() created MYappExecPluginThing!!!");
so.addParam("allowScriptAccess", "always");
log("init() added Param!!");
so.write(elId);
log("init() wrote!");
IE9's console (yeah, you read that right) shows
init()
created MYappExecPluginThing!!!
init() added Param!!
init() wrote!
but none of the debugging i've got in MYappExePluginThing.as displays and nothing else happens.
I'm trying to figure out what I've screwed up/what's going on? Is MYappExePluginThing.as running? Is it waiting on something? Did it fail? Why aren't the log messages in MYappExePluginThing.as showing up?
The first most obvious thing is I'm using FDT which, I suspect, was not used to build the original. Is there some kind of magic "build javascript accessible swf thing" in FlashBuilder or some other IDE?
First noteworthy thing I find is:
file MYappExePluginThing.swf
MYappExePluginThing.swf Macromedia Flash data (compressed), version 14
I'm using Flex 4.6 which, for all I know, may have a completely different mechanism for allowing javascript communication than was used in appExePluginThing.swf
Does anyone know if that's true?
For example, when FDT runs this thing (I can compile but FDT does not create a .swf unless i run it) I get a warning in the following method:
private function init() : void
{
Log.log("console.log", "MYappExePluginThing init()");
//var initCallback:String = Application.application.parameters.initCallback?Application.application.parameters.initCallback:"MYjavascript.MYappExePluginThing_init";
var initCallback:String = FlexGlobals.topLevelApplication.parameters.initCallback?FlexGlobals.topLevelApplication.parameters.initCallback:"MYjavascript.MYappExePluginThing_init";
try
{
ExternalInterface.addCallback("method1Callback",method1);
ExternalInterface.addCallback("method2Callback",method2);
ExternalInterface.call(initCallback);
}
catch(err:Error)
{
Log.log("console.log", "MYappExePluginThing init() ERROR err="+err);
}
}
I got a warning that Application.application was deprecated and I should change:
var initCallback:String = Application.application.parameters.initCallback?Application.application.parameters.initCallback:"MYjavascript.MYappExePluginThing_init";
to:
var initCallback:String = FlexGlobals.topLevelApplication.parameters.initCallback?FlexGlobals.topLevelApplication.parameters.initCallback:"MYjavascript.MYappExePluginThing_init";
which I did but which had no effect on making the thing work.
(FYI Log.log() is something I added:
public class Log{
public static function log(dest:String, mssg:String):void{
if(ExternalInterface.available){
try{
ExternalInterface.call(dest, mssg);
}
catch(se:SecurityError){
}
catch(e:Error){
}
}
trace(mssg);
}
}
)
Additionally, in MYjavascript.js MYappExePluginThing_init looks like this:
this.MYappExePluginThing_init = function () {
log("MYjavascript.js - MYappExePluginThing_init:");
};
Its supposed to be executed when MYappExePluginThing finishes initializing itself.
Except its not. The message is NOT displaying on the console.
Unfortunately, I cannot find any references explaining how you allow javascript communication in Flex 4.6 so I can check if I've got this structured correctly.
Is it a built in kind of thing all Flex/Flash apps can do? Is my swf getting accessed? Is it having some kind of error? Is it unable to communicate back to my javascript?
Does anyone have any links to references?
If this was YOUR problem, what would you do next?
(Not a full solution but I ran out of room in the comment section.)
To answer your basic question, there's nothing special you should need to do to allow AS3-to-JS communication beyond what you've shown. However, you may have sandbox security issues on localhost; to avoid problems, set your SWFs as local-trusted (right-click Flash Player > Global Settings > Advanced > Trusted Location Settings). I'm guessing this not your problem, though, because you'd normally get a sandbox violation error.
More likely IMO is that something is broken due to decompilation and recompilation. SWFs aren't meant to do that, it's basically a hack made mostly possible due to SWF being an open format.
What I suggest is that you debug your running SWF. Using break-points and stepping through the code you should be able to narrow down where things are going wrong. You can also more easily see any errors your SWF is throwing.
Not really an answer, but an idea to get you started is to start logging everything on the Flash side to see where the breakage is.
Since you're using IE, I recommend getting the Debug flash player, installing it, then running Vizzy along side to show your traces.
Should give you a good idea of where the app is breaking down.
Vizzy
Debug Player

Firefox ChromeWorker not loading script

I have a requirement where I need to communicate with native code to perform some operations. I have been successful by using JS-Ctypes and things are panning out as expected. Since the communication from my web application with the native code takes some time, thus blocking the main JS thread consequently freezing the UI.
Thus I need to create a separate thread to be delegated with the communication with the native code and post back results to the main thread which will give the appropriate feedback to the user. Firefox ChromeWorker are exactly what I need to use, since they are independent threads with access to JS-Ctypes.
My problem is that for the life of me, I can't seem to load a script using that approach. This is what I currently have:
main.js
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
Components.utils.import("resource://gre/modules/Services.jsm");
var worker = new ChromeWorker("js/fpman/myworker.js");
worker.onmessage = function(e){
console.log(e.data);
};
worker.postMessage('start');
myworker.js
self.onmessage = function(e){
var sum = 1 + 1;
postMessage("Sum is " + sum);
};
When that code runs in the main JS, I get this error on firebug console
Failed to load script: http://localhost:8080/myapp/js/fpman/myworker.js (nsresult = 0x805303f4)
Point to note, when I use a normal worker thread i.e
var worker = new Worker("js/fpman/myworker.js");
the js file (myworker.js) is loaded fine and I get the expected result, but of course that doesn't suffice my needs since a normal worker doesn't have access to JS-Ctypes. So it seems the problem is how am creating the ChromeWorker. Could someone please enlighten me on how to appropriately instantiate and use the ChromeWorker Object from an application. I have seen a lot of reference of usage of ChromeWorker in extensions, but that is not what I want, I want to use the ChromeWorker in my web application.
Thanks.
That particular error is NS_ERROR_DOM_BAD_URI
I don't believe what you are doing will work, and I know it won't work very soon in Firefox because enablePrivilege is going away completely.

Categories