activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Mielke (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AMQ-6533) Stomp raises command and data error when unmarshaling with large stomp message
Date Fri, 09 Dec 2016 11:23:58 GMT

    [ 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)

Mime
View raw message