14

Simple question, I want to set 24 or 12 hours timeout in Node.js to periodically (once or twice a day) check some db data and clean suspicious garbage, if any.

Is there any possible problems or performance issues, caused by setting huge timeout, that i need to be aware of? I don't mind if it's not exact 12-24hr in ms, and don't mind loosing this timeout on server crash, as I will run same garbage collector on server startup anyway.

Conclusion:

  • I'm not using native OS cron to run separate script as I need to access current Node.js process data inside this script.
  • In the end I decided to use https://www.npmjs.com/package/cron package for its ability to shedule at specific time (presumably on time of low server load).
  • Thanks everyone for quick responses!
Max Yari
  • 3,617
  • 5
  • 32
  • 56

3 Answers3

11

I've had success using the package cron. It's simple to use and is generally compatible with a CronTab. I've had a job that runs once a month and this has worked consistently since last year, so I can attest to it.

That being said, this package ultimately does just use setTimeout internally so there's no real issue with you doing that. If your timeout number is too large (larger than the maximum JavaScript integer) there may be a problem, but 1000 * 60 * 60 * 24 is significantly smaller than that.

Obviously if your system goes down or the script crashes for some other reason the timeout won't work.

You could also just use crontab directly if it's available (or Windows task scheduling).

Explosion Pills
  • 188,624
  • 52
  • 326
  • 405
  • To clarify: `cron` **is** the Unix/Linux daemon that processes the `crontab` file. This daemon *("service")* runs on the system all the time, watching the `crontab` file, and he's the one that actually launches the activities at the proper time. Other operating-systems do it differently ... but *every* operating-system does it. Somehow. – Mike Robinson May 07 '15 at 15:02
  • @MikeRobinson yes, thanks for the clarification. On Unix it's as simple as running `crontab -e` to set it up and then point to a script. You could even use the node interpreter to run a JavaScript script! – Explosion Pills May 07 '15 at 15:03
  • Problem is, that i need to acces internal data of current node.js app from this script, therefore i don't think that running separate script by OS is a nice fit here. By the way, yes, i'm on Unix. `Cron` module looks interesting, still reading about it, if all it does is ultimately running setTimeout in app with handy functionality on top then i will just move on with plain setTimeout. – Max Yari May 07 '15 at 15:12
  • On the other hand it's pretty usefull that i can set it up on specific time presumably to do the job when server load is minimal. And if, as Mike said, cron package uses native Unix service, that awesome. I suppose i will stick with this option, Thanks for response, have a nice day =) – Max Yari May 07 '15 at 15:22
4

Personally, I would use a cron job to do this sort of thing (in Unix/Linux), or a "scheduled task" in Windows. In any case, the work would be done entirely on the server, by the server ... and thus, there's really no reason to have a JavaScript app (on "some other" computer) to be involved with it.

More generally: "no, don't tell someone to 'go to sleep for 12 hours,' somehow trusting that this means s/he will wake up in time." Instead, use an alarm-clock. Calculate the absolute-time at which the activity should [next] occur, then see to it that the activity does occur "not-sooner." Arrange for the computer that actually needs to do the work, to do the work at the appropriate time, using whatever scheduling facilities are available on that computer.

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41
  • But if `setTimeout` doesn't have any problems, it means you can create a timeout within some hideously nested inner scope and still have access to variables etc. Using an external process to kick it off may be complex. – James Thorpe May 07 '15 at 15:02
  • JavaScript here is for Node.js, meaning that it WILL be done and timeouted in the server code, no third party involved. – Max Yari May 07 '15 at 15:02
  • I'm sorry, Max, but I really don't understand you here. Is the JavaScript code being executed **on** "the server in question?" I don't ordinarily think of such a thing as being the case. – Mike Robinson May 07 '15 at 16:15
  • @MikeRobinson Oh sorry Mike, i did not saw this comment of yours. Yes, if it is not clear yet, JavaScript is executed on the server (one from the initial question), meaning inside server's code. It's a `Node.js` server, `Node.js` basically runs on JavaScript. – Max Yari May 07 '15 at 16:55
  • Okay. Unusual, but okay. Nevertheless, I think of a server as being "responsive." Something nudges it, and then it moves. If there's a purely maintenance task that needs to occur "every night at 1am," then I wouldn't be using `Node.js` to do that. I'd be using `cron` or its equivalent. – Mike Robinson May 07 '15 at 17:48
1

There should not be any problem at all, but in my opinion it is just better to do this thing with a OS cron job. This will use the OS timer, will call your node app; that will be clear to everybody, even to the one who has never seen node or JavaScript in action. Also it will automatically protect you from long-term memory leaks because your app will be killed after each iteration.

smnbbrv
  • 23,502
  • 9
  • 78
  • 109
  • Do you mean creating a separate app to do this job? My node.js app is a server and it's working all the time resieving HTTP's and TCP's, and in fact, to judge what is garbage - i need to access this app's internal data like collection of sockets. It is possible to export and try to run insynch those data in db for example, but feels like too much buzz for such a simple task. – Max Yari May 07 '15 at 15:08
  • As I said above, I guess I don't fully understand your setup. I don't think of "javascript" as running anywhere else but "in a browser [on a computer far, far, away ...]" And so, even if the two activities ARE running on the very same computer, I'm "frankly skeptical" that this is really the best way to proceed. I could of course be wrong, so I'm not saying that *you're* wrong . . . – Mike Robinson May 07 '15 at 16:18