[
https://issues.apache.org/jira/browse/QPIDJMS-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039410#comment-16039410
]
Keith Wall edited comment on QPIDJMS-293 at 6/7/17 6:04 PM:
------------------------------------------------------------
The change looks good and confirm that I am unable to reproduce my original
problem.
(below updated 2017/06/07)
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 (say, bytes message of size AMQP
frame size +1) results in a *single* {{BinaryWebSocketFrame}} being sent
(which comprises the many transfers).
Turning the logs up I see:
{noformat}
[1767460652:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (262122)
"\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x03\x00Ss\xc0b\x0a\xa1/ID:3aa56b9f-3d52-493d-acaa-59b4845f70ac:1:1:1-1@\xa1\x05queue@@@\xa3\x18application/octet-stream@@\x83\x00\x00\x01\x5c\x83\xb5\xf9\x05\x00Su\xb0\x00\x04\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"...(truncated)
[1767460652:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (180)
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
18:59:20.109 [AmqpProvider:(1):[amqpws://localhost:5671]] TRACE
o.a.q.j.t.netty.NettyWsTransport - Attempted write of: 262344 bytes
{noformat}
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 websocket message that will be
received (or turn the check off, which the Jetty authors don't recommend).
was (Author: k-wall):
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]
