Their is no internal limitation in Undertow. Do you have a simple reproducer I can look at? Stuart On Wed, Mar 23, 2016 at 2:52 AM, Robin Anil <robin.anil(a)gmail.com&gt; wrote: > Stuart, > > We are using undertow websocket library for passing back and forth > serialized JSON messages using Websockets.sendText method > > On the client side in Chrome we are noticing that that instead of 1 message > we are receiving 2 where the first one is truncated at some 323,821 B and > the second message is of 148,583 but malformed (its text but its garbled) > and therefore not a JSON even if its concatenated with the first message > > We are converting protocol buffers to JSON on the server side and can't > point the finger at that code as it had worked for even bigger JSON > messages. > > To investigate this further I need help ruling out any message size or frame > size limitation on undertow that could cause this. Any pointers here would > be helpful. > > Robin

Sounds like a bug in the extension, can you file a JIRA about this? Stuart On Thu, Apr 7, 2016 at 3:33 AM, Robin Anil <robin.anil(a)gmail.com&gt; wrote: > Sorry for not getting back because I didn't have a repro case. This issue > happened last night and I was noticing that it was because the per-message > size was in the 300K to 500K range. > > So I tried to reduce our payload our issue went away. Digging in I noticed > that the moment I disable PerMessageDeflateHandshake() extension the error > goes away even at the large batch size. So this is what I have as an repro > so far > > > Robin > > On Tue, Mar 22, 2016 at 5:30 PM Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: >> >> Their is no internal limitation in Undertow. Do you have a simple >> reproducer I can look at? >> >> Stuart >> >> On Wed, Mar 23, 2016 at 2:52 AM, Robin Anil <robin.anil(a)gmail.com&gt; wrote: >> > Stuart, >> > >> > We are using undertow websocket library for passing back and forth >> > serialized JSON messages using Websockets.sendText method >> > >> > On the client side in Chrome we are noticing that that instead of 1 >> > message >> > we are receiving 2 where the first one is truncated at some 323,821 B >> > and >> > the second message is of 148,583 but malformed (its text but its >> > garbled) >> > and therefore not a JSON even if its concatenated with the first message >> > >> > We are converting protocol buffers to JSON on the server side and can't >> > point the finger at that code as it had worked for even bigger JSON >> > messages. >> > >> > To investigate this further I need help ruling out any message size or >> > frame >> > size limitation on undertow that could cause this. Any pointers here >> > would >> > be helpful. >> > >> > Robin