All requests from single client target the same worker thread

[kstewart83]

I'm doing some stress testing and I noticed that each request from a client targets the same worker thread. Furthermore, the client cannot make further requests until the previous request is acknowledged.

Is this a purposeful design decision?

Where this might be an issue is if the worker thread is slow to acknowlege. In an extreme example, say a client issues an event where it takes the server one second to acknowledge. If the client issues four requests in quick succession (which might not block on the client side), currently they each block on the server and the total time taken is four seconds. If these were routed to different worker threads and four threads were available, the same requests would take a total time of one second.

I figure the "right" solution when you know an event could take a while to process is to always acknowledge immediately, process the event in a separate thread, and then send an event asynchronously to the client. I was looking at this situation when the server thread blocks implicitly (i.e., through a long computation or accessing disk or the network).

I'm primarily using a Java SocketIO client, but saw the same behavior in the Javascript client as well.

[kstewart83]

I just realized I probably also need to check to make sure client isn't internally blocking. The "emit" call doesn't block, but maybe some blocking is going on in the Manager.

[mrniko]

The "emit" call doesn't block, but maybe some blocking is going on in the Manager.

There is no any blocking if you look closely to the code.

[PeterL1n]

Met the same issue here. Can't receive concurrent event call from the same client.

[kvn-pavan]

Hi @mrniko I just came across the same issue. Is there a work around for this one?