tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob DeRemer <>
Subject RE: weird behavior using Tomcat 7 JSR-356 client implementation in standalone multi-threaded test client
Date Sun, 03 Nov 2013 18:53:27 GMT

> -----Original Message-----
> From: Mark Thomas []
> Sent: Sunday, November 03, 2013 11:24 AM
> To: Tomcat Users List
> Subject: Re: weird behavior using Tomcat 7 JSR-356 client implementation in
> standalone multi-threaded test client
> 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

Thanks Mark - yeah, we haven't ruled out our client code yet, so we're going to make sure
that's as simple as possible.  If we can come up with a somewhere reproducible case, we'll
post back.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message