![]() I called process._getActiveHandles() before the setTimeout of the working timer and got 21 handles. One callback is working as expected which is a bit strange. 2 is not working in the sense that I can step the code and see that setTimeout() is indeed called with sensible values and does not throw. I have 3 timers I can access via the api. Ok, so I have successfully been able to connect the debugger over a ssh tunnel. I do appreciate you insights and guesses though. Which I can agree is a pretty strong indication too. The only thing that doesn't indicate a bug/change in setTimeout/setInterval to me is probably that there isn't 500 people reporting it already due to node being so popular. Granted our sw is also newer on the newer installations but a few of the "workers" hasn't been changed in well over a year. This happened on several servers during the summer (running 10.4.1-10.6.0) but not on any of our 60+ servers running <= 9.8.0. So I find it improbable (but I suppose not impossible) that all these functions have a bug in them that manifest at the same time. Most of the functions are rather small and easy to overview. A third one is querying the NTP status on the server etc. Another checks a local database and talks to a local service. One of my "workers" query an api over the network. So any error or exception should be caught I think (I have double checked that all promises are returned and not just created locally too). I hear what you are saying about unhandled rejections but I do have that catch before the then that sets the timer. I'm sure there are more advanced monitors.īut back to the issue at hand. Using external schedule trigging had not even occurred to me! Today the node process is kept alive using a systemd service that limits memory and tasks and restarts the node process if needed while ensuring always up. I also warmly recommend turning on warnings (in production) for safety and using an APM (application performance monitoring) tool and setting up alerts for uptime and certain tasks.Īgain, I strongly believe this is an issue with Node's user experience (not your or most people's code) and I feel strongly that Node (well, us) should fix no problem, I didn't feel particularly 'accused' because it it was an easy fix I could do to my code I want to know about it so I can fix the problem :D Typically, not on the server and using something that does scheduling - either what your cloud provides, crons if you're on a VM, k8s/cron jobs etc. Perhaps there are a better construct to keep some "background tasks" executing but I thought this was simple enough to do its job. Also it's possible your problem was entirely different and we do have a bug in setInterval - so take everything I say (guess) with a grain of salt. I'm getting "off" timer land and into "promise debugging land" here - just saying this is entirely on our radar and something we're thinking and talking about improving. Many people don't log warnings in production. ![]() recurring tasks fail, but since Node doesn't exit on promise unhandled rejection warnings the server chugs on.there is a networking "hickup" and stuff fails for just a second or two.If there is a way to get the "unhandledRejection" warnings then there is a very high chance you'll see it there. To be clear, I am not accusing you of writing code problematically - I am saying Node should guide users to safer ways to write code and make them "obvious".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |