tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Preißer <>
Subject RE: setting the text or binary buffer size for websockets
Date Wed, 20 Nov 2013 00:14:16 GMT
Hi Johan,

> -----Original Message-----
> From: Johan Compagner []
> Sent: Tuesday, November 19, 2013 6:13 PM
> To: Tomcat Users List
> Subject: Re: setting the text or binary buffer size for websockets
> >
> > > I expect that i can send now 32K at
> > > once of text (or binary) withing that "continuation frame"
> >
> > The buffer sizes control the input buffer - i.e. they control the
> > maximum size of a message that can be received if an application doesn't
> > support partial messages.
> >
> > The output buffers are all 8K.
> >
> > The splitting of a WebSocket message into multiple frames should be
> > transparent to the application.
> >
> >
> ah thx.
> But then i think a doc needs to be updated:
> that doesn't tell me at all that it only input buffers, the property name
> doesn't say that and also the text doesn't mention that at all
> it just says: "The default buffer size for text messages is 8192 bytes" and
> many times in java that means an output buffer.
> But i did some more testing, and i think the ChatAnnotation should be
> altered as an example, because now it just does this:
>   private static void broadcast(String msg) {
>         for (ChatAnnotation client : connections) {
>             try {
>                 client.session.getBasicRemote().sendText(msg);
> So without any synchronization it sends text..
> And this can happen in many threads (depending on which chat client makes
> the message)
> But i notice now that we have to sync around that line. If i don't do that
> then when sending large message (that will be split up in frames) funny
> stuff happens with a lot of weird exceptions on the browser side
> I am not 100% sure yet, still testing but it seems that if i sync around
> .getBasicRemote().sendText(msg); that it will work out fine
> But if i don't do that it doesn't work.

Right, I also think the calls to getBasicRemote().sendText(...) should be synchronized as
multiple threads can concurrently access this method for a particular client (that however
could mean that if one client stops receiving from its WebSocket connection, no other client
can receive messages - to solve this, e.g. one could use a dedicated thread for each client
which takes and sends messages from a queue, or use the RemoteEndpoint.Async).
Oracle's javadoc of RemoteEndpoint.Basic says:

"If the websocket connection underlying this RemoteEndpoint is busy sending a message when
a call is made to send another one, for example if two threads attempt to call a send method
concurrently, or if a developer attempts to send a new message while in the middle of sending
an existing one, the send method called while the connection is already busy may throw an

However, even after adding synchronization, I get stability issues and several exceptions
on current Tomcat 8 trunk when sending large messages. I have filed a report here (I don't
know if these are the same issues that you got):

Konstantin Preißer

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

View raw message