Ok more information it was not the back to back writes that are done on the client side, I have a bytebuffer message that is 23,000 bytes and thats where the error with code 1002 happens sometimes not 100% of the time about 2 out of 5 times. However an 800 byte message in a bytebuffer has no problem 100% of the time.
On Tue, Dec 2, 2014 at 4:08 PM, Jason Ricles <jgr...@alum.lehigh.edu> wrote: > No luck try to find a blocking call or having the websocket server > reader go off into another thread. so basically no way around this > problem it seems? > > On Tue, Dec 2, 2014 at 9:19 AM, Mark Thomas <ma...@apache.org> wrote: >> On 02/12/2014 13:05, Jason Ricles wrote: >>> Mark, >>> >>> Is there any way to do two back to back writes to a websocket with a >>> sort of blocking technique, and without using a sleep? >> >> Use one of the blocking methods (i.e. one without a Future or SendHandler). >> >> A variation way is to call setBatchingAllowed(true), call the writes >> (probably with the blocking methods) and then setBatchingAllowed(false). >> If the messages are smaller than the buffer, they'll set in the buffer >> and then you'll get a blocking write to empty the buffer when you call >> setBatchingAllowed(false). >> >> I should add that the Javadoc isn't as clear about the expected >> behaviour for non-blocking writes as it is for blocking writes but the >> model as I understand it is that the previous write has to complete >> before the next write can start. >> >> Mark >> >>> >>> On Mon, Dec 1, 2014 at 3:13 PM, Mark Thomas <ma...@apache.org> wrote: >>>> On 01/12/2014 18:30, Jason Ricles wrote: >>>>> What might be causing this error on concurrent writes in a websocket, >>>> >>>> The fact you are doing concurrent writes? The Java WebSocket API doesn't >>>> allow that. And it should stop you with a suitable exception. >>>> >>>> Mark >>>> >>>>> CloseReason: code [1002], reason [The client frame set the reserved >>>>> bits to [2] which was not supported by this endpoint]? >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
