I have a Fastify web server that exposes a bunch of RESTful endpoints. I created my project using fastify-cli and I also use the CLI to run the server locally. I notice that whenever I rapidly call my APIs, I get the following error in my terminal:
You'll notice that I call the same API repeatedly. I don't get any errors in the first two or three calls but, when I call the same API a third or fourth time, the server process crashes and automatically restarts a few seconds later.
Since the logs are sparse, I can't seem to figure out what might cause this issue and I wonder if it is an issue with the CLI itself? Appreciate any help from other Fastify users.
It is a known bug with the watch feature cli issue
not fixed yet.
Related
I have a node.js app that is intended to be running all the time. Is a core process that does some specific work for each of our clients.
Today, that app is feed with the clients data by a config (json) file on startup, every time we need to add/remove a client or change a client data, we edit the json and kill/restart the app.
I came with the idea of building another node.js app that should work as a cli to send instructions to the main app, I don't know where to start, is there a solution already for this?
I tought of using sockets to connect the app with the cli, but I feel it overkill.
What's the propper way of controlling a node.js app from another node.js app?
I know this question may be vague and leaves space for discussions and opinions, but I don't know where to start looking for, all my searches give me express.js or forever/pm2 articles.
You could try storing your data in a REDIS DB and subscribing to changes from the node applications. So, you could update the redis and the configuration changes trigger automatically from within node application
See this question
Another method is to emit global events from your CLI and have your apps listen to and update their code as required.
I'm receiving SIGSEGV quite randomly when running an express app with PM2. The strange thing is the server runs quite well for the past few weeks. It does not print any error message except:
App [XXX] with id [7] and pid [27757], exited with code [255] via signal [SIGSEGV]
After implementing the "segfault-handler" module, I started to receive some stack traces. It seems the app encounters a few different segmentation fault:
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd211f87330]
node(_ZN2v88internal9HashTableINS0_15ObjectHashTableENS0_20ObjectHashTableShapeENS0_6HandleINS0_6ObjectEEEE18FindInsertionEntryEj+0x40)[0xc0b680]
node(_ZN2v88internal15ObjectHashTable3PutENS0_6HandleIS1_EENS2_INS0_6ObjectEEES5_i+0x124)[0xc0c0a4]
node(_ZN2v88internal7Runtime17WeakCollectionSetENS0_6HandleINS0_16JSWeakCollectionEEENS2_INS0_6ObjectEEES6_i+0x59)[0xc7d639]
node(_ZN2v88internal25Runtime_WeakCollectionSetEiPPNS0_6ObjectEPNS0_7IsolateE+0x11d)[0xc7d89d]
[0x2acdd80963b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f0fc311c330]
node(_ZN2v88internal32IncrementalMarkingMarkingVisitor26VisitFixedArrayIncrementalEPNS0_3MapEPNS0_10HeapObjectE+0x376)[0xad8a16]
node(_ZN2v88internal18IncrementalMarking4StepElNS1_16CompletionActionENS1_18ForceMarkingActionENS1_21ForceCompletionActionE+0x2c1)[0xad6181]
node(_ZN2v88internal8NewSpace15SlowAllocateRawEiNS0_19AllocationAlignmentE+0x74)[0xb05244]
node(_ZN2v88internal4Heap11AllocateRawEiNS0_15AllocationSpaceES2_NS0_19AllocationAlignmentE+0x1b9)[0xa678c9]
node(_ZN2v88internal4Heap20AllocateFillerObjectEibNS0_15AllocationSpaceE+0x19)[0xab00b9]
node(_ZN2v88internal7Factory15NewFillerObjectEibNS0_15AllocationSpaceE+0x2d)[0xa67d1d]
node(_ZN2v88internal29Runtime_AllocateInTargetSpaceEiPPNS0_6ObjectEPNS0_7IsolateE+0x5e)[0xc99e8e]
[0x249862c06355]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fbebabd2330]
node(_ZN2v88internal9HashTableINS0_15ObjectHashTableENS0_20ObjectHashTableShapeENS0_6HandleINS0_6ObjectEEEE18FindInsertionEntryEj+0x40)[0xc0b680]
node(_ZN2v88internal15ObjectHashTable3PutENS0_6HandleIS1_EENS2_INS0_6ObjectEEES5_i+0x124)[0xc0c0a4]
node(_ZN2v88internal7Runtime17WeakCollectionSetENS0_6HandleINS0_16JSWeakCollectionEEENS2_INS0_6ObjectEEES6_i+0x59)[0xc7d639]
node(_ZN2v88internal25Runtime_WeakCollectionSetEiPPNS0_6ObjectEPNS0_7IsolateE+0x11d)[0xc7d89d]
[0x125b9620963b]
I know there is little information here. Can anyone please tell me a good way to start diagnosing? I've checked the PM2 log, mongoDB log but no luck.
Thanks!
Mars
Since the stack trace is different every time and not very illuminating, all you can do is try things. The first main suspects will be things that use native code because it's not that likely that plain Javascript is causing a segFault. It is probably native code that is somehow corrupting memory or not properly interacting with the garbage collector in node.js.
So, the things to look for are the interaction between your current version of node.js and the things you have that use native code (such as mongoDB). Here are things to try:
Identify all modules that use native code and temporarily remove any that you can live without.
Upgrade both node.js and mongoDB to recent versions in case you have some interaction between their specific versions that is causing the problem. If you can't upgrade node.js to a recent stable version, then make absolutely sure that all the modules you are running are certified to be stable with the version of node.js that you do have.
Restart your server just in case there's anything goofed up in the OS that is contributing to the problem.
Start with a clean database or run some sort of database check on your database in order to verify that there is no corruption there.
Whenever you update your DB scheme, make sure you have a strategy for moving the prior database forward (it looks like in MongoDB you can just make sure you assign a default value to new scheme elements).
Gather new info after making changes and repeat the process, trying to only change one thing at a time so that if it fixes the issue you will know exactly which item it was that fixed it.
Something like that can happen when you copy the code with node_modules that included binary modules compiled for a different architecture than the one you're trying to run it on.
Try either removing node_modules and running npm install from scratch, or you can try running npm rebuild without removing node_modules.
What is the recommended workflow to debug Foxx applications?
I am currently working on a pretty big application and it seems to me I am doing something wrong, because the way I am proceeding does not seem to be maintanable at all:
Do your changes in Foxx app (eg new endpoints).
Upload your foxx app to ArangoDB.
Test your changes (eg trigger API calls).
Check the logs to see if something went wrong.
Go to 1.
i experienced great time savings, shifting more of the development workflow to the terminal client 'arangosh'. Especially when debugging more complex endpoints, you can isolate queries and functions and debug each individually in the terminal. When done debugging, you merge your code in Foxx app and mount it. Require modules as you would do in Foxx, just enter variables as arguments for your functions or queries.
You can use arangosh either directly from the terminal or via the embedded terminal in the Arangodb frontend.
You may also save some time switching to dev mode, which allows you to have changes in your code directly reflected in the mounted app without fetching, mounting and unmounting each time.
That additional flexibility costs some performance, so make sure to switch back to production mode once your Foxx app is ready for deployment.
When developing a Foxx App, I would suggest using the development mode. This also helps a lot with debugging, as you have faster feedback. This works as follows:
Start arangod with the dev-app-path option like this: arangod --javascript.dev-app-path /PATH/TO/FOXX_APPS /PATH/TO/DB, where the path to foxx apps is the folder that contains a database folder that contains your foxx apps sorted by database. More information can be found here.
Make your changes, no need to deploy the app or anything. The app now automatically reloads on every request. Change, try out, change try out...
There's currently no debugging capabilities. We are planning to add more support for unit testing of Foxx apps in the near future, so you can have a more TDD-like workflow.
I have a nodejs (express) app running on heroku.
I need to keep a short history of logs (up to a day or so).
I need to be able to dig in to the stack trace of any errors being thrown
I have been able to solve the first two by using Loggly but I can't find any solution which will show me the stack trace of any exceptions which have been thrown.
I'd recommend using node-airbrake module on your app, connecting either to the webservice or to an own set-up server-instance for the notification backend using errbit gem.
For setting things up, it depends, which way you want to go.
To keep it simple, i'd recommend using the 30-day free-trial hosted service and in case, you're happy with it, to setup your own errbit instance.
I have been struggling to do the tutorial, https://www.windowsazure.com/en-us/develop/nodejs/tutorials/web-app-with-mongodb/, which basically makes a simple node.js application that has access to a Mongo DB. I keep running into the following issue when launching the program locally with the command Start-AzureEmulator:
"No connection could be made because the target machine actively refused it 127.0.0.1:27017"
I tried various ports and configurations with no success. Oddly enough, when I run mongodb.exe, the database launches without hiccup (this is just through the command line not within the Azure Emulator). I have also tried reinstalling all of the tools multiple times. It seems I am at a loss of what to do next.
Have any of you experienced this problem or have been able to complete this tutorial?
As a side note, do any of you know any cloud providers that allow the use of sockets with node.js? This is one of the main reasons I am trying to use Azure.
I assume you've followed the instructions step by step and haven't modified anything yet?
I note from the screenshot below, that the sample tries to open Mongo at 127.255.0.1:27017, not 127.0.0.1:27017:
I suggest checking your Azure services' URL's in case you're looking for Mongo on the wrong address.