On 21 November 2013 12:21, Niki Dokovski <nick...@gmail.com> wrote: > On Thu, Nov 21, 2013 at 1:11 PM, Johan Compagner <jcompag...@servoy.com > >wrote: > > > > > > > Hi, > > > > > > > > > https://javaee-spec.java.net/nonav/javadocs/javax/websocket/OnMessage.html > > > > > > if i read that, then if i have > > > > > > onmessage(String) > > > > > > that i get the whole message as once. > > > > > > Where is it really specified that that also means that it must also fit > > in > > > the input buffer? > > > So it can't be a partial at all? > > > > > > For me the difference between this: > > > > > > > > > onmessage(String msg) > > > onmessage(String msg,boolean lastPart) > > > > > > means that i do the streaming my self.. So i take the parts that are > > > there, store it, save it whatever i want. So that only the buffer size > is > > > kept in memory (so it is really streaming) > > > > > > If i don't do that "lastPart" that just means that i want the whole > > > message as once, no matter how it it send to the server, or better > said, > > > how it is handled by tomcat (or what ever webserver) internally , how > big > > > input buffers the webserver uses. > > > > > > For example tomcat uses by default 8KB. If i know that all my messages > > are > > > smaller then that, then i wouldn't do that lastPart boolean. But then > my > > > application is deployed on something else, that has a input buffer size > > of > > > 4KB and my message doesn't fit in there. Now i suddenly have to do the > > > partial myself, and my app is broken > > > This doesn't look right to me.. Because now it really looks to me that > > all > > > apps should include always that boolean param.. Because how do you > know? > > Or > > > you must be really sure that the message are not passing a buffer > > boundary > > > (but maybe an implementation uses 256 bytes) > > > > > > -- > > > Johan Compagner > > > Servoy > > > > > > > > > To follow up on this a little bit > > > > this one: > > > > onmessage(Reader reader) > > > > only works also on the "whole" message > > that is weird because you don't have i think really this support: > > > > onmessage(Reader reader, boolean lastPart) (at least that is not > specified > > here: > > > https://javaee-spec.java.net/nonav/javadocs/javax/websocket/OnMessage.html > > ) > > > > But in a reader that sounds just weird, the reader should just block > until > > all parts are feeded to the reader.. > > But that also doesn't work it fails. > > So what is really the point of the reader param in this scenario? > > > > Without being part of JSR 356 EG, the rationale of the cited APIs can be > observed at protocol fragmentation support [1]. The point is that you may > have cases where you need parts of message transferred and not the entire > one. > > > [1] http://tools.ietf.org/html/rfc6455#section-5.4 > >
But the thing is, it is purely tomcat making frames/fragmentation. The browser (chrome in my part) sends over just 1 frame (14K or what ever size i have now already test that send over 50K of data in 1 frame, no idea what exactly the frame buffer size is of chrome, i haven't hit that one yet) but tomcat internally divides it up in 8K and then suddenly it is "framed" but over the line from the browser to the server it where not frames it was just one. i am currently reading also this http://download.oracle.com/otn-pub/jcp/websocket-1_0-fr-spec/JavaWebSocketAPI_1.0_Final.pdf and nowhere i can find (4.7 for example) that a whole message can only by 1 frame.. They even have a standard limit see 4.7.1 where maxMessageSize is defined, that is default -1 and that means that it can be unlimited.(but that's not true in tomcat it is limited by the input buffer size) I am still thinking that tomcat implementation interprets it wrong. A whole message is really what it is, the complete message, constructed out of X number of frames.. So tomcat should handle the concatting for me, why do i need to do that my self? Only if i specify that i want to have partial messages (the boolean arg) then i get the frames or better said the buffer sizes of tomcat.
