You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jim Gomes (JIRA)" <ji...@apache.org> on 2007/09/11 02:59:22 UTC

[jira] Created: (AMQNET-59) Unmarshalling Bytes Message does not read NULL terminating byte

Unmarshalling Bytes Message does not read NULL terminating byte
---------------------------------------------------------------

                 Key: AMQNET-59
                 URL: https://issues.apache.org/activemq/browse/AMQNET-59
             Project: ActiveMQ .Net
          Issue Type: Bug
          Components: Stomp
         Environment: Windows XP SP2
.NET 2.0
STOMPConnect 1.0
TIBCO EMS 4.2.0
            Reporter: Jim Gomes
            Assignee: James Strachan
            Priority: Critical
         Attachments: StompWireFormat.cs.patch.txt

The [STOMP protocol specification|http://docs.codehaus.org/display/STOMP/Protocol] states that a bytes message frame should still be NULL terminated even when the content-length header is specified.  The StompWireFormat.Unmarshal() function does not read this final terminating NULL byte when unmarshaling a bytes message.  This messes up the parsing of the next message to be sent to the consumer, and it will be discarded as an unknown format message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (AMQNET-59) Unmarshalling Bytes Message does not read NULL terminating byte

Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQNET-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Gomes resolved AMQNET-59.
-----------------------------

    Resolution: Fixed

> Unmarshalling Bytes Message does not read NULL terminating byte
> ---------------------------------------------------------------
>
>                 Key: AMQNET-59
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-59
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: Stomp
>         Environment: Windows XP SP2
> .NET 2.0
> STOMPConnect 1.0
> TIBCO EMS 4.2.0
>            Reporter: Jim Gomes
>            Assignee: James Strachan
>            Priority: Critical
>         Attachments: StompWireFormat.cs.patch.txt
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The [STOMP protocol specification|http://docs.codehaus.org/display/STOMP/Protocol] states that a bytes message frame should still be NULL terminated even when the content-length header is specified.  The StompWireFormat.Unmarshal() function does not read this final terminating NULL byte when unmarshaling a bytes message.  This messes up the parsing of the next message to be sent to the consumer, and it will be discarded as an unknown format message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (AMQNET-59) Unmarshalling Bytes Message does not read NULL terminating byte

Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/AMQNET-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40119 ] 

Jim Gomes commented on AMQNET-59:
---------------------------------

Note: the patch was generated after applying the patches for [AMQNET-53] and [AMQNET-56].

> Unmarshalling Bytes Message does not read NULL terminating byte
> ---------------------------------------------------------------
>
>                 Key: AMQNET-59
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-59
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: Stomp
>         Environment: Windows XP SP2
> .NET 2.0
> STOMPConnect 1.0
> TIBCO EMS 4.2.0
>            Reporter: Jim Gomes
>            Assignee: James Strachan
>            Priority: Critical
>         Attachments: StompWireFormat.cs.patch.txt
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The [STOMP protocol specification|http://docs.codehaus.org/display/STOMP/Protocol] states that a bytes message frame should still be NULL terminated even when the content-length header is specified.  The StompWireFormat.Unmarshal() function does not read this final terminating NULL byte when unmarshaling a bytes message.  This messes up the parsing of the next message to be sent to the consumer, and it will be discarded as an unknown format message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (AMQNET-59) Unmarshalling Bytes Message does not read NULL terminating byte

Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQNET-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Gomes closed AMQNET-59.
---------------------------


> Unmarshalling Bytes Message does not read NULL terminating byte
> ---------------------------------------------------------------
>
>                 Key: AMQNET-59
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-59
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: Stomp
>         Environment: Windows XP SP2
> .NET 2.0
> STOMPConnect 1.0
> TIBCO EMS 4.2.0
>            Reporter: Jim Gomes
>            Assignee: James Strachan
>            Priority: Critical
>         Attachments: StompWireFormat.cs.patch.txt
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The [STOMP protocol specification|http://docs.codehaus.org/display/STOMP/Protocol] states that a bytes message frame should still be NULL terminated even when the content-length header is specified.  The StompWireFormat.Unmarshal() function does not read this final terminating NULL byte when unmarshaling a bytes message.  This messes up the parsing of the next message to be sent to the consumer, and it will be discarded as an unknown format message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.