Rob Gillan

We have made sure all of the 5 production nodes are at the latest 0.2.22 module, but still seeing errors such as: `SubError [TimeoutError]: operation timed out at afterTimeout (/opt/nisient/lib/node/node_modules/bluebird/js/release/timers.js:46:19)...

Any news on this, this problem is persisting: `SubError [TimeoutError]: operation timed out at afterTimeout (/opt/nisient/lib/node/node_modules/bluebird/js/release/timers.js:46:19) at Timeout.timeoutTimeout [as _onTimeout] (/opt/nisient/lib/node/node_modules/bluebird/js/release/timers.js:76:13) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7) `

We moved to memcache-pp (and more recently, memcache-ppp) which appears to have addressed the issue.

Just trying to do the same with a client test set up environment where we need to generate 100's of k of client connections. Working with primary IP (64k clients)...

Been able to isolate this in AWS world. tcpdump showed that indeed node.js was correctly selecting the localAddress for the output interface, but wasn't hitting the destination from the virtual...

still hitting a port limit when the combined port count hits ~64k (ie. 32k on each interface). Not sure if this is an AWS or somewhere buried in the ubuntu...

Thanks for getting back. The client side is working ok with secondary IPs. Issue was on the total connection count on the server side, and even though we'd adjusted the...

We also suspect there's a leak somewhere and we're trying to isolate (using node with remote inspector/chrome tools) but in our case it's with very large numbers of effectively idle...

I know this is a really old ticket but we're still using dGrid/dStore and dojo 1.17 (hard to go past such a solid reliable framework). We are running into the...

So we are also seeing that the Port and User setting in the -F config file is not being used for the connection. We have overcome this issue by sshping...