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