[
https://issues.apache.org/jira/browse/QPIDJMS-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039410#comment-16039410
]
Keith Wall commented on QPIDJMS-293:
------------------------------------
The change looks good and confirm that I am unable to reproduce my original
problem.
However, I think there is an analogous change required on the sending side.
{{org.apache.qpid.jms.transports.netty.NettyWsTransport#send}} should be
prepared to write a {{BinaryWebSocketFrame}} with final fragment {{false}}
followed by a series of {{ContinuationWebSocketFrame}} frames if {{output}} is
large. Currently sending a very large JMS message results in a correspondingly
large {{BinaryWebSocketFrame}}. Receiving this is quite awkward on the server
side: for instance, in Jetty based implementations you need to tune
{{#maxBinaryMessageSize}} to be sufficiently large to accommodate the largest
message that will be sent (or turn the check off, which the Jetty authors don't
recommend).
> the WebSocket transport does not handle continuation frames
> -----------------------------------------------------------
>
> Key: QPIDJMS-293
> URL: https://issues.apache.org/jira/browse/QPIDJMS-293
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.23.0
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Fix For: 0.24.0
>
>
> the WebSocket transport does not handle continuation frames, only the primary
> Binary frames, it needs to handle both. Indentified from investigation of
> followup comments on QPIDJMS-290 once 0.23.0 was under vote.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
