[
https://issues.apache.org/jira/browse/CXF-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5798.
------------------------------
Resolution: Fixed
Fix Version/s: 3.0.1
fixed the issue using one approach that buffers the output for the initial
response.
This approach inevitably limits the size of the response message that can be
sent back (note that this is only about the initial response message and not
about subsequently pushed response messages. Those subsequent responses by
written by the service application to the socket are sent back as individual
messages without buffering, Hence there is no size limit for them)
To overcome this limitation, the fragment handling may be added in the cxf's
websocket binding to transport large response messages. But again, the counter
part can be implemented in CXF's websocket conduit, but that won't help for
other clients (e.g. js clients).
So this open part can be tracked separately.
> WebSocket transport fails to transport a large message
> ------------------------------------------------------
>
> Key: CXF-5798
> URL: https://issues.apache.org/jira/browse/CXF-5798
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.0.0
> Reporter: Aki Yoshida
> Assignee: Aki Yoshida
> Fix For: 3.0.1
>
>
> There is an issue for the server to reliably transmit the entire message.
> The original server side (i.e., Destination) implementation associates each
> write operation from the application to a websocket write operation. When the
> message is large and split in this way, this will confuse the client to
> interpret the message.
> Either the fragment flag must be set at the write operation at the server or
> the message must be buffered (if the client is not supporting the fragment).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
