You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Rafael H. Schloming (JIRA)" <ji...@apache.org> on 2013/10/21 14:46:45 UTC
[jira] [Resolved] (PROTON-323) Regression: Messenger sends "null"
in disposition state after accept
[ https://issues.apache.org/jira/browse/PROTON-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael H. Schloming resolved PROTON-323.
----------------------------------------
Resolution: Not A Problem
The 0.5 behaviour is actually correct. The reason the disposition is null is because the incoming window is zero and so the delivery is settled as soon as get is called. The accept() in this code snippet is actually a noop because the message has already fallen off the zero sized window. If you add the line "mng.incoming_window = 1" to the code snippet, then it behaves similarly to 0.4, e.g.:
[0x251fe20:0] -> @disposition(21) [role=true, first=0, last=0, settled=false, state=@accepted(36) []]
Note the state=@accepted(36) above.
> Regression: Messenger sends "null" in disposition state after accept
> --------------------------------------------------------------------
>
> Key: PROTON-323
> URL: https://issues.apache.org/jira/browse/PROTON-323
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Reporter: Ted Ross
> Assignee: Rafael H. Schloming
> Priority: Blocker
> Fix For: 0.6
>
>
> Using the following Python code snippet:
> from proton import *
> mng = Messenger()
> mng.start()
> mng.subscribe("amqp://0.0.0.0/Queue_1")
> mng.timeout=100
> mng.recv()
> msg = Message()
> t = mng.get(msg)
> mng.accept(t)
> mng.stop()
> The following trace is seen after the call to stop:
> [0xf7f6a0:1] -> DISPOSITION @21 [true, 0, 0, true, null]
> On Proton 0.4, this problem does not exist. The trace is:
> [0x1087bb0:1] -> DISPOSITION @21 [true, 0, 0, true, @36 []]
--
This message was sent by Atlassian JIRA
(v6.1#6144)