I'm troubleshooting an OAuth Authentication issue (invalid_grant) where one of two possible causes is the server's clock being out of sync with NTP. I've ensured the server's clock is synchronized.
Does nodejs instantiate its own clock or reference the system clock?
I expect it would reference the system clock. I only ask because restarting nodejs temporarily fixes the issue (invalid_grant), and I would like to rule out time synchronization.
There are two way nodejs handle time.
using javascript Date or using process.hrtime
Assuming node core uses process.hrtime and you absolutely need to know, I would take a look at the libuv uv_hrtime function which node uses.
Maybe you have found a bug on the uv_hrtime. Whenever I use process.hrtime I never had problem like I did using Date
hope this points you at righ direction.
Related
I am having a small problem with an application ran by pm2 cluster mode. Normally everything is working fine, but due to the logic of my application and recently switching to cluster mode i am now facing an issue, i can't handle properly without refactoring my application from the ground.
My application uses express for http-request handling and uses also global variables to store data, timers, etc. Now after switching to pm2 cluster mode, only one of the instances has a value, but the others don't. Thats resulting in problems, because of inconsistencies over the different instances. The behaviour is clear, but i would have to refactor many things to make the application in whole work properly again.
I already saw things like the INSTANCE_VAR, but could not find out how that could help me.
All i can think of at the moment is, am i able to force pm2 to send a http request to all instances simultanously, or if not can i tell pm2 to handle my request with a specific instance, which i define on the runtime from the outside and without interfering the other instances?
I am actually having something similar were i want a specific api request to make an update available registered only on process. Here i found a way to send a message/event to a specific process, i think it may help
Is it possible to use nodes os.cpus() module on react?
Trying to figure out how to get real time cpu usage updates from node on a project on working on. I have played around with react before but i am still a newb and i haven't touched on node yet, so this is proving to be difficult for me.
update: I need the cpu data to be displayed in the site i am making
You can get the stats of the server system through an API call.
However, to get the stats of the client system is not possible as browsers are supposed to be run in sandbox mode to stop websites from reading the client system or changing it.
Using Node.js, how can I compute the time since the current process (the one running node) was started?
Ideally I'd like a cross-platform solution but a macOS-only solution would also be okay.
Unfortunately it is impossible for me to inject any code into Node.js startup. My library will only be loaded at some unknown point after the process starts.
The function process.uptime() (available since v0.5.0) returns the number of seconds the current Node.js process has been running. I don't have a Mac to check, but there's no caveat in the documentation that it only works on certain platforms.
Is there anything that is similar to PHP's APC (Alternative PHP Cache) for Node.js?
So every Node.js thread running on a server can access the cache. I know the architecture of Node.js may not easily or at all allow for an APC like cache.
I know we can of course run memcache on each server as well to create a server level cache but was curious of there was any alternative.
thanks
Node is trying to keep only the basic stuff in its API, so you won't find such a thing "baked in" (for example WebSockets isn't included in Node core, but in external modules).
You would need to create such a cache layer using something like Redis or Memcached.
P.S. You should better refer to Node processes instead of threads, since you don't have to handle threading stuff with Node.
I don't know if this module helps at all.
I can't guarantee its' reliability and I never kept my promise to do a Windows API as I'm a bit of a linux snob (as in nothing Microsoft comes near my PC)
https://github.com/dazhazit/node-ipcbuffer
It implements a simple byte buffer between processes. You could probably build any mechanism you like on top of it.
So the first app that people usually build with SocketIO and Node is usually a chatting app. This chatting app basically has 1 Node server that will broadcast to multiple clients. In the Node code, you would have something like.
//Psuedocode
for(client in clients){
if(client != messageSender){
user.send(message);
}
}
This is great for a low number of users, but I see a problem with this. First of all, there is a single point of failure which is the Node server. Second of all, the app will slow down as the number of clients grow. What is there to do then when we reach this bottleneck? Is there an architecture (horizontal/vertical scaling) that can be used to alleviate this problem?
For that "one day" when your chat app needs multiple, fault-tolerant node servers, and you want to use socket.io to cross communicate between the server and the client, there is a node.js module that fits the bill.
https://github.com/hookio/hook.io
It's basically an event emitting framework to cross communicate between multiple "things" -- such as multiple node servers.
It's relatively complicated to use, compared to most modules, which is understandable since this is a complex problem to solve.
That being said, you'd probably have to have a few thousand simultaneous users and lots of other problems before you begin to have problems with this.
Another thing you can do, is try to develop your application in a way so that if a connection is lost (which happens all the time anyway), eg. server goes down, client has network issues (eg. mobile user), etc, your application should be able to handle that and recover from such issues gracefully.
Since Node.js has a single event-loop thread, this single point of failure is written into its DNA. Even reloading a server after code changes require this thread to be stopped.
There are however a lot of tools available to handle such failures gracefully. You could use forever; a simple CLI tool for ensuring that a given script runs continuously. Other options include distribute and up. Distribute is a load balancing middleware for Node. Up builds on top of Distribute to offer zero downtime reloads using either a JavaScript API or command line interface:
Further reading I find you just need to use Redis Store with Socket.io to maintain connection references between two or more processes/ servers. These options have already been discussed extensively here and here.
There's also the option of using socket.io-clusterhub if you don't intend to use the Redis store.