On 03/11/2013 02:29, Bob DeRemer wrote: > BACKGROUND: We've created a test client that spins up multiple > websocket clients - each in their own thread. While using their own > thread isn't very resource efficient, that's ok. We want each > client's send/receive to be isolated from each other. Our client > logic is using a JSR356 client that extends Endpoint and implements > Whole<byte[]>. In addition, we have message synchronization, so each > client will not send a new request until it's received the > corresponding respone (i.e. we have our own req/resp messages with > unique IDs). > > Our client is running the JVM with the following: java -Dserver -Dd64 > -Xms24G -Xmx48g -XX:+UseNUMA -XX:+UseG1GC > > PROBLEM We are seeing a problem when running multiple clients. It > appears that we're sending messages on 1 websocket client, but > sometimes receiving the message on a different websocket. It can be > as little as 1000 or as many as 25000. It seems to depend on how > fast responses are received whether we see the problem. We have > checked the server logging and have verified that all messages have > been received and sent back on the proper websocket connection. > > QUESTION When using Tomcat's JSR-356 client implementation in a > standalone java app, what kind of threading does it use under the > hood when messages are received? Is there any possibility that there > can be any cross-talk?
The client uses AsynchronousSocketChannel under the covers. It maintains its own thread pool although Tomcat provides a thread factory so the threads get sensible names. Each incoming block of data should be processed with a separate thread. Much of the code is shared between the client and server implementations. I don't see any obvious chances for cross-talk. Is the error (when it occurs) consistent? ie. client 4 always gets client 5's responses or is it random? Consistent would point to an issue during connection setup, random to an issue during connection processing. It is certainly possible that there is a Tomcat bug here. If it is hard to reproduce then code inspection might find it but we need to narrow down the area to look in. Keep in mind it could be a client bug too. When it occurs, it would be worth checking the clients concerned. E.g. have the managed to end up with the same message handler for instance. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
