You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2017/11/28 19:34:28 UTC
Correct behavior for message delivery when receiver link is locally closed
I noticed a discrepancy on how PN_DELIVERY is handled by different bindings
1. C++ - if (link is locally closed and auto_accept is set) { release the
message } else { call on_message }
2. Python - if (link is locally closed) { if (auto_accept is set) release
the message} else call on_message
3. Go always calls on_message
I think 1. is correct. auto_accept=true avoids surprising messages after
receiver.close() has been called, and releases the messages politely.
auto_accept=false gives the application complete control.
2. completely drops messages after a local close - no release, no
settlement, no notice to the application. This seems wrong.
In particular if you want to close close a link but process all messages
that were "on the way" then the natural pattern is to send detach and
process all messages till you get the remote detach back/ 2. makes this
impossible as the binding will drop messages after the local detach. 1.
means that if auto_accept=false the application is informed of *all*
messages incoming regardless of local link state which means the app can
decide what to do - accept or release.
Thoughts? I'll fix them all to do 1. if nobody raises counter arguments.
Cheers,
Alan.
Re: Correct behavior for message delivery when receiver link is
locally closed
Posted by Gordon Sim <gs...@redhat.com>.
On 28/11/17 19:34, Alan Conway wrote:
> I noticed a discrepancy on how PN_DELIVERY is handled by different bindings
>
> 1. C++ - if (link is locally closed and auto_accept is set) { release the
> message } else { call on_message }
> 2. Python - if (link is locally closed) { if (auto_accept is set) release
> the message} else call on_message
> 3. Go always calls on_message
>
> I think 1. is correct. auto_accept=true avoids surprising messages after
> receiver.close() has been called, and releases the messages politely.
> auto_accept=false gives the application complete control.
>
> 2. completely drops messages after a local close - no release, no
> settlement, no notice to the application. This seems wrong.
I agree; 1 is best, 2 is wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Correct behavior for message delivery when receiver link is
locally closed
Posted by Chuck Rolke <cr...@redhat.com>.
+1
----- Original Message -----
> From: "Alan Conway" <ac...@redhat.com>
> To: "Andrew Stitcher" <as...@redhat.com>, "Clifford Jansen" <cj...@redhat.com>, "Justin Ross"
> <jr...@redhat.com>, "Gordon Sim" <gs...@redhat.com>, users@qpid.apache.org
> Sent: Tuesday, November 28, 2017 2:34:28 PM
> Subject: Correct behavior for message delivery when receiver link is locally closed
>
> I noticed a discrepancy on how PN_DELIVERY is handled by different bindings
>
> 1. C++ - if (link is locally closed and auto_accept is set) { release the
> message } else { call on_message }
> 2. Python - if (link is locally closed) { if (auto_accept is set) release
> the message} else call on_message
> 3. Go always calls on_message
>
> I think 1. is correct. auto_accept=true avoids surprising messages after
> receiver.close() has been called, and releases the messages politely.
> auto_accept=false gives the application complete control.
>
> 2. completely drops messages after a local close - no release, no
> settlement, no notice to the application. This seems wrong.
>
> In particular if you want to close close a link but process all messages
> that were "on the way" then the natural pattern is to send detach and
> process all messages till you get the remote detach back/ 2. makes this
> impossible as the binding will drop messages after the local detach. 1.
> means that if auto_accept=false the application is informed of *all*
> messages incoming regardless of local link state which means the app can
> decide what to do - accept or release.
>
> Thoughts? I'll fix them all to do 1. if nobody raises counter arguments.
>
> Cheers,
> Alan.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org