FiledĀ https://issues.jboss.org/browse/UNDERTOW-684

On Wed, Apr 6, 2016 at 4:57 PM Stuart Douglas <sdouglas@redhat.com> wrote:
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@gmail.com> 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@redhat.com> 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@gmail.com> 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