[ 
https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349117#comment-14349117
 ] 

ASF subversion and git services commented on PROTON-833:
--------------------------------------------------------

Commit 8f810c3757c21ef32589b1bdd276e83d21659eb3 in qpid-proton's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8f810c3 ]

PROTON-833: check the local channel is still set


> transport can emit frames with an invalid channel number after local session 
> close
> ----------------------------------------------------------------------------------
>
>                 Key: PROTON-833
>                 URL: https://issues.apache.org/jira/browse/PROTON-833
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-j
>    Affects Versions: 0.8
>            Reporter: Robbie Gemmell
>            Assignee: Robbie Gemmell
>
> The transport can emit frames with an invalid channel number after a local 
> session close is performed.
> A side effect of calling close on the session is that the channel number is 
> unmapped when the end frame is sent, and the associated field set to the 
> value -1. The transport can subsequently send frames which then use this -1 
> value, treating it as channel 65535 when sent to represent the unsigned 
> channel number. For example, if a local link close(+detach?) call is 
> performed in response to a remote detach after a local session close is 
> performed, a detach frame can be emitted with channel 65535. Similarly, I 
> have noticed disposition frames being sent with channel 65535.
> Proton-C appears to protect against thse situations by inspecting whether the 
> channel number has been set as >= 0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to