You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Torsten Mielke (JIRA)" <ji...@apache.org> on 2016/12/09 11:23:58 UTC
[jira] [Comment Edited] (AMQ-6533) Stomp raises command and data
error when unmarshaling with large stomp message
[ https://issues.apache.org/jira/browse/AMQ-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735031#comment-15735031 ]
Torsten Mielke edited comment on AMQ-6533 at 12/9/16 11:23 AM:
---------------------------------------------------------------
The reason for seeing both warnings is the following:
{{StompWireFormat.unmarshal()}} correctly returns a {{StompFrameError}} command when the message payload exceeds {{StompWireFormat.MAX_DATA_LENGTH}}.
This command is then processed in {{ProtocolConverter.onStompCommand()}}:
{code}
public void onStompCommand(StompFrame command) throws IOException, JMSException {
try {
if (command.getClass() == StompFrameError.class) {
throw ((StompFrameError)command).getException();
}
...
} catch (ProtocolException e) {
handleException(e, command);
// Some protocol errors can cause the connection to get closed.
if (e.isFatal()) {
getStompTransport().onException(e);
}
}
}
{code}
which re-throws the exception, catches it and calls {{handleException()}}.
{{ProtocolConverter.handleException()}} creates and sends a stomp error response back to the client.
Thereafter it executes above line
{{getStompTransport().onException(e);}}
which asynchronously stops the transport.
Given that the transport connection is stopped async in a new thread, it happens that the error response is sent back to the client and the tcp transport thread continues to read the next command from the sockets input stream *before* the transport got closed by the extra thread.
Also given that we have so far read only read 100 MB out of 105 MB data from the input stream, there is another 5 MB to read. However the Stomp transport expects to read the next Stomp command (which is bound to 1024 bytes) and exhausts the 1024 bytes and next raises the error {{The maximum command length was exceeded.}}.
Other than the two warnings, which can be misleading, there is not other side effect resulting from this bug problem.
was (Author: tmielke):
The reason for seeing both warnings is the following:
{{StompWireFormat.unmarshal()}} correctly returns a {{StompFrameError}} command when the message payload exceeds {{StompWireFormat.MAX_DATA_LENGTH}}.
This command is then processed in {{ProtocolConverter.onStompCommand()}}:
{code}
public void onStompCommand(StompFrame command) throws IOException, JMSException {
try {
if (command.getClass() == StompFrameError.class) {
throw ((StompFrameError)command).getException();
}
...
} catch (ProtocolException e) {
handleException(e, command);
// Some protocol errors can cause the connection to get closed.
if (e.isFatal()) {
getStompTransport().onException(e);
}
}
}
{code}
which re-throws the exception, catches it and calls {{handleException()}}.
{{ProtocolConverter.handleException()}} creates and sends a stomp error response back to the client.
Thereafter it executes above line
{{getStompTransport().onException(e);}}
which asynchronously stops the transport.
Given that the transport connection is stopped async in a new thread, it happens that the error response is sent back to the client and the tcp transport thread continues to read the next command from the sockets input stream *before* the transport got closed by the extra thread.
Also given that we have so far read only read 100 MB out of 105 MB data from the input stream, there is another 5 MB to read. However the Stomp transport expects to read the next Stomp command (which is bound to 1024 bytes) and exhausts the 1024 bytes and next raises the error {{The maximum command length was exceeded.}}.
> Stomp raises command and data error when unmarshaling with large stomp message
> ------------------------------------------------------------------------------
>
> Key: AMQ-6533
> URL: https://issues.apache.org/jira/browse/AMQ-6533
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, stomp
> Affects Versions: 5.14.2
> Reporter: Torsten Mielke
> Labels: broker, stomp
>
> The size of a Stomp message is restricted to StompWireFormat.MAX_DATA_LENGTH (100 MB by default).
> For messages of higher payload size the broker will correctly raise this warning
> {code}
> 2016-12-09 11:59:56,752 [0.1:59434@59432] - WARN ProtocolConverter - Exception occurred processing: <Unknown> -> org.apache.activemq.transport.stomp.ProtocolException: The maximum data length was exceeded
> {code}
> (Ignore the '<Unknown>' for now).
> However if a stomp client sends a 105 MB message, this results in two warnings being raised in the broker's log:
> {code}
> 2016-12-09 11:59:56,752 [0.1:59434@59432] - WARN ProtocolConverter - Exception occurred processing: <Unknown> -> org.apache.activemq.transport.stomp.ProtocolException: The maximum data length was exceeded
> 2016-12-09 11:59:56,757 [0.1:59434@59432] - WARN ProtocolConverter - Exception occurred processing: <Unknown> -> org.apache.activemq.transport.stomp.ProtocolException: The maximum command length was exceeded
> {code}
> where only the first of these two warnings should appear as only one message was sent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)