Here is the wireshark of the binary data that is being transferred over.
00 00 00 00 00 00 00 00 00 00 00 00 86 dd 60 00 ..`.
0010 00 00 5c 15 06 40 00 00 00 00 00 00 00 00 00 00 ..\..@..
0020 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
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 proble
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 wrote:
> On 02/12/2014 13:05, Jason Ricles wrote:
>> Mark,
>>
>> Is there any way to do two back to b
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 setBatchingAll
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?
On Mon, Dec 1, 2014 at 3:13 PM, Mark Thomas wrote:
> On 01/12/2014 18:30, Jason Ricles wrote:
>> What might be causing this error on concurrent writes in a websocket,
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 cli
What might be causing this error on concurrent writes in a websocket,
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-unsub
