You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2017/06/07 18:04:18 UTC
[jira] [Comment Edited] (QPIDJMS-293) the WebSocket transport does
not handle continuation frames
[ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org