[
https://issues.apache.org/jira/browse/QPID-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192380#comment-13192380
]
Gordon Sim edited comment on QPID-3777 at 1/24/12 7:08 PM:
-----------------------------------------------------------
I don't like having the client library automatically mark link bindings as
session scoped. That seems to me like something that should be explicitly asked
for. For one thing it would invalidate a more 'normal' usage in
durable/reliable subscriptions to an xml- or headers- exchange.
The broker side change is a new feature/extension as much as a bug fix. I'm not
un-sympathetic to the desire for such an extension. My concern would be to
avoid having it tie us (and those using it, unless they explicitly so choose)
to the pre-1.0 AMQP model. Put another way, while I'm not opposed to the broker
side change, I would not myself encourage anyone to use it and would not want
to have to keep supporting it, certainly not on 1.0 based sessions.
One minor criticism of the broker side change is the inclusion of the user- and
connection- identifiers in the stored tuple. I would argue those should be
taken from the context of the unbind call when it is made. Though in practice
there will be no difference, it seems more in line with the spirit of the code
(where those are used for permission checking and therefore it is the
permission of the unbind not the bind that counts).
was (Author: gsim):
I don't like having the client library automatically mark link bindings as
session scoped. That seems to me like something that should be explicitly asked
for. For one thing it would invalidate a more 'normal' usage in
durable/reliable subscriptions to an xml- or headers- exchange.
The broker side change is a new feature/extension as much as a bug fix. I'm not
un-sympathetic to the desire for such an extension. My concern would be to
avoid having it tie us (and those using it, unless they explicitly so choose)
to the pre-1.0 AMQP model. Put another way, while I'm not opposed to the broker
side change, I would not myself encourage anyway to use it and would not want
to have to keep supporting it, certainly not on 1.0 based sessions.
One minor criticism of the broker side change is the inclusion of the user- and
connection- identifiers in the stored tuple. I would argue those should be
taken from the context of the unbind call when it is made. Though in practice
there will be no difference, it seems more in line with the spirit of the code
(where those are used for permission checking and therefore it is the
permission of the unbind not the bind that counts).
> Messaging API link binding is not unbound if client disconnects uncleanly
> -------------------------------------------------------------------------
>
> Key: QPID-3777
> URL: https://issues.apache.org/jira/browse/QPID-3777
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, C++ Client
> Affects Versions: 0.12
> Reporter: Jason Dillaman
> Priority: Minor
> Attachments: QPID-3777.patch
>
>
> Description of problem:
> Link bindings within the Messaging API (e.g. 'test.q;{create:always,
> node:{type:queue},link:{x-bindings:[{exchange:test.ex,queue:test.q,key:#}]}}')
> are implemented solely within the client. Therefore, if the connection
> between the broker and the client is severed, the client will not be able to
> remove the link binding as it normally would during a clean client disconnect.
> How reproducible:
> 100%
> Steps to Reproduce:
> 1. Create a link binding via a C++ Messaging API sender or receiver
> 2. Kill the client or sever the link between the client and broker
>
> Actual results:
> The link binding is still present in the broker
> Expected results:
> The link binding would be unbound when the broker discovers the client was
> disconnected
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
