[
https://issues.apache.org/jira/browse/QPID-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189173#comment-13189173
]
[email protected] commented on QPID-3767:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3546/#review4470
-----------------------------------------------------------
Looks good overall.
/trunk/qpid/cpp/src/qpid/broker/Bridge.cpp
<https://reviews.apache.org/r/3546/#comment10023>
Is there a backward compatibility issue with adding the new fields at the
front?
/trunk/qpid/cpp/src/qpid/broker/Link.cpp
<https://reviews.apache.org/r/3546/#comment10036>
I'm not keen on failing over in maintenance visit. That is potentially a
long delay till a broker reconnects. I think we need to be able to trigger
reconnects immediately on detecting a close.
/trunk/qpid/cpp/src/qpid/broker/Link.cpp
<https://reviews.apache.org/r/3546/#comment10034>
Not sure I understand the retry semantics, I think this can be simplified.
E.g. if the next url isn't different you should keep going till you find one
that is, not fall thru to the currentInterval logic. Likewise if next returns
false, you should just keep going from the start, not fall thru.
/trunk/qpid/cpp/src/qpid/broker/LinkRegistry.cpp
<https://reviews.apache.org/r/3546/#comment10040>
Throw rather than assert?
/trunk/qpid/cpp/src/qpid/broker/LinkRegistry.cpp
<https://reviews.apache.org/r/3546/#comment10041>
ditto
/trunk/qpid/specs/management-schema.xml
<https://reviews.apache.org/r/3546/#comment10042>
Why is this RC rather than RO? Can you change durability?
- Alan
On 2012-01-19 14:22:45, Kenneth Giusti wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3546/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-01-19 14:22:45)
bq.
bq.
bq. Review request for qpid, Alan Conway, Gordon Sim, michael goulish, and Ted
Ross.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. This patch modifies the way the broker's Link and Bridge objects are
identified and managed. Specifically:
bq.
bq. 1) both Bridge and Links are now identified by explict names assigned by
management, rather than destination host/port info.
bq. - names beginning with the prefix "qpid." are reserved for qpidd
internal use.
bq. - for backward compatibility, if no name is assigned on creation, the
broker will generate a name based on UUID
bq. 2) the corresponding QMF objects have been updated accordingly, with the
additions of:
bq. - the QMF Link object has been updated to provide a reference to the
corresponding Connection
bq. - the QMF Link object has been modified to allow the
host/port/connectionRef to change on failover
bq. - the QMF Bridge object has been modified to allow the Channel
identifier to change (allowing Bridges to be reassigned to different links in
the future)
bq. 3) Links/Bridges may now be created/deleted via the QMF Broker's generic
"create" and "delete" methods
bq. 4) Some consolidation of the Link/Bridge creation APIs, specifically:
bq. - Link/Bridges are created via calls to the LinkRegistry's "declare()"
methods
bq. - Link/Bridges are removed by calling their corresponding "destroy()"
methods
bq.
bq. More importantly, the above changes make it possible to create multiple
Links between the same two brokers. This can be done by creating Links to the
same destinations with different names. This is a change from the existing
behavior, which uses the destination host/port as the unique Link identifier.
bq.
bq.
bq. This addresses bug qpid-3767.
bq. https://issues.apache.org/jira/browse/qpid-3767
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/qpid/cpp/src/qpid/broker/Bridge.h 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/Bridge.cpp 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/Connection.cpp 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/Link.h 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/Link.cpp 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/LinkRegistry.h 1233125
bq. /trunk/qpid/cpp/src/qpid/broker/LinkRegistry.cpp 1233125
bq. /trunk/qpid/cpp/src/tests/federation.py 1233125
bq. /trunk/qpid/specs/management-schema.xml 1233125
bq.
bq. Diff: https://reviews.apache.org/r/3546/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. This patch fails to pass some of the cluster tests - I'm investigating
this now. All non-cluster federation tests where passing (prior to my latest
rebase).
bq.
bq. Work remains, but I wanted to get this patch out for discussion before
going much farther.
bq.
bq.
bq. Thanks,
bq.
bq. Kenneth
bq.
bq.
> Federation link index becomes invalid on failover against a cluster.
> --------------------------------------------------------------------
>
> Key: QPID-3767
> URL: https://issues.apache.org/jira/browse/QPID-3767
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.14
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Fix For: 0.15
>
>
> The Link management object that represents a connection between two federated
> brokers is indexed (identified) by the remote broker's host and port. If the
> remote broker is part of a cluster, and a failover event occurs, the
> host:port used by the Link object's index may no longer exist. This prevents
> the route from being deleted.
> For example, create a cluster of two brokers using addresses 127.0.0.1:2222
> and 127.0.0.1:3333. Start a third broker, say 127.0.0.1:8888. Create a
> queue route from 127.0.0.1:2222 to an exchange on 127.0.0.1:8888. Kill the
> broker 127.0.0.1:2222. This results in a Link object that is connected to
> 127.0.0.1:3333, but reports 127.0.0.1:2222 as it's host.
> [kgiusti@localhost src]$ qpid-config -a 127.0.0.1:2222 add queue src
> [kgiusti@localhost src]$ qpid-config -a 127.0.0.1:8888 add exchange fanout
> destx
> [kgiusti@localhost src]$ qpid-config -a 127.0.0.1:8888 add queue dest
> [kgiusti@localhost src]$ qpid-config -a 127.0.0.1:8888 bind destx dest
> [kgiusti@localhost src]$ qpid-route queue add 127.0.0.1:8888 127.0.0.1:2222
> destx src
> [kgiusti@localhost src]$ ../examples/messaging/spout -b 127.0.0.1:2222
> --content "ZZZ" src
> [kgiusti@localhost src]$ ../examples/messaging/drain -b 127.0.0.1:8888 -t 2
> dest
> Message(properties={spout-id:8c308c74-6b25-4408-8694-93ef8352a308:0,
> x-amqp-0-10.routing-key:src}, content='ZZZ')
> <Kill Broker 127.0.0.1:2222, link fails over to 127.0.0.1:3333>
> From qpid-tool:
> qpid: show 133
> Object of type:
> org.apache.qpid.broker:link:_data(bc33c1b3-25cd-e0ce-04d7-ad684ed36d91)
> Attribute 133
> =================================================
> vhostRef 150
> host 127.0.0.1
> port 2222
> transport tcp
> durable False
> state Operational
> lastError Failed over to tcp:10.16.185.15:3333
> Once this occurs, I am unable to delete the link:
> [kgiusti@localhost src]$ qpid-route queue del 127.0.0.1:8888 127.0.0.1:2222
> destx src
> [kgiusti@localhost src]$ qpid-tool 127.0.0.1:8888
> qpid: list
> Summary of Objects by Type:
> Package Class Active Deleted
> =======================================================
> org.apache.qpid.broker binding 14 0
> org.apache.qpid.broker system 1 0
> org.apache.qpid.broker broker 1 0
> org.apache.qpid.broker bridge 1 0
> org.apache.qpid.broker link 1 0
> org.apache.qpid.broker subscription 5 0
> org.apache.qpid.broker connection 2 0
> org.apache.qpid.broker session 2 0
> org.apache.qpid.broker queue 6 0
> org.apache.qpid.broker exchange 9 0
> org.apache.qpid.broker vhost 1 0
--
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]
