If the disk is under unusually heavy load (or the response times are long for other reason), I'd assume that the current synchronous fs calls in is.js can cause the process event loop to be blocked for an unnecessarily long time when receiving a burst of change notifications or performing the initial directory tree scan (looks like is.directory is even called twice for each directory).
I suspect that this is currently causing timeouts in my project as the Node process isn't able to process user/socket ping requests for a few users that have their disks under heavy load (e.g. https://github.com/airdcpp-web/airdcpp-share-monitor/issues/2).
If the disk is under unusually heavy load (or the response times are long for other reason), I'd assume that the current synchronous fs calls in
is.js
can cause the process event loop to be blocked for an unnecessarily long time when receiving a burst of change notifications or performing the initial directory tree scan (looks likeis.directory
is even called twice for each directory).I suspect that this is currently causing timeouts in my project as the Node process isn't able to process user/socket ping requests for a few users that have their disks under heavy load (e.g. https://github.com/airdcpp-web/airdcpp-share-monitor/issues/2).