> > > 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: http://tomcat.apache.org/tomcat-8.0-doc/web-socket-howto.html 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. Is that logical? even getAsyncRemote doesn't work either.. (this is for me very weird,i would have expected that the async remote would solve this problem anyway) johan
