At work we’ve been doing a technical book club. It’s been a lot of fun to learn about technologies that we don’t actively use at work. We worked through a (currently) free online jQuery book found here. We had pretty ok results with that – It’s kind of obvious based on the quality that they are currently in beta, and they don’t provide any exercises for any of the lessons so it’s a little more like a handbook/pocket guide than an education tool. After that we decided to read Node.js in Action.
Node.js is a pretty cool technology. I personally have a few reservations about Node, but so far I am fond of it. I’m not ready to just jump all in and say it’s the best thing ever, but I do like how fast and easy it is to set up and get things running.
For our team’s continuous integration server we use JetBrains TeamCity. Recently we updated to the latest 8.1 build and started using their windows domain authentication module. With less than 1 minute of setup, we can now use our network credentials. When we did this, we also wanted to set up SSL to keep our network credentials safe. We don’t want to waste money on an SSL certificate that will only be used by people inside of our company, on our internal network, so instead we created a certificate signed by our Active Directory’s root CA. That way all of the windows computers on our domain will trust the certificate and all of the Mac/Mobile devices can just have the AD CA’s certificate installed on them manually.
For some reason that I couldn’t figure out, the Tomcat server that TeamCity uses served up the SSL certificate just fine to browsers, but not to Java clients. After hours of not being able to figure this out, I decided to try out my new Node.js skills. Using node-http-proxy I setup a proxy to go https to the proxy, then insecure https to Tomcat. This was an extra layer of indirection that shouldn’t have been required, but it works.
After I finished the proxy and finished testing everything, I ran into what I consider a flaw of Node.js. When node encounters an unhanded exception, node just shuts down. It’s not much different than how other applications act, but IIS will automatically restart the web server whereas node doesn’t do this out of the box. One solution is to just put a global exception handler on your application
|
1 2 3 4 |
process.on('uncaughtException', function(err) { // handle the error safely console.log(err); }); |
But this only ensures that the application won’t crash. If you restart the machine, you’ll still have to go start up the server.
If you’re using Unix then you can just create your own /etc/init.d/ script depending on your specific distribution. If you’re in Windows, things get more difficult. In windows, it’s always been a pain to create a service. That is, until I discovered the Non-Sucking Service Manager (NSSM).
NSSM allows you to setup any executable to be it’s own service. You can specify the executable, the name of the service, and dozens of other configuration options. The most useful of which is a configuration for what to do when the executable quits unexpectedly (defaults is to restart the executable).
Head over to nssm.cc and download NSSM.
- Unzip the download of NSSM
- run cmd.exe and cd to the unzipped directory.
- run nssm install <service name> and a GUI will open. Configure as desired and save.
All it takes to get everything set up is a global exception handler and NSSM to install the Windows Service. A simple solution to this silly problem.
Note: if you’re using Unix you can use forever (or something similar) to restart Node.js, and then set up your startup script. But forever seems to not work quite right in Windows.