> On 2012-01-20 12:19:14, Gordon Sim wrote: > > This in essence reverts > > http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/Bridge.cpp?r1=707515&r2=709342&pathrev=709532 > > where the bridges own UUID was replaced with the brokers federation tag. > > The comment for the commit states this was done to make it "easier to > > determine which queues go to which brokers".
Ah, good find - I didn't realize that. "Easier"... I could debate that :) - took me awhile to find where that uuid is visible from (hint: check vhost qmf object). Since this "feature" is totally undocumented - aside from that log entry - do we really need to preserve this? Can't the same information be made available via the QMF schema? (I think it may be - the Subscription can be traced back to the Connection, albeit indirectly). Otherwise, I can back this change out. Perhap suffix the queue name with a simple sequence number? - Kenneth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3560/#review4486 ----------------------------------------------------------- On 2012-01-20 00:01:40, Kenneth Giusti wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/3560/ > ----------------------------------------------------------- > > (Updated 2012-01-20 00:01:40) > > > Review request for qpid, Gordon Sim, michael goulish, and Ted Ross. > > > Summary > ------- > > The fix replaces the per-broker federation uuid with a unique uuid for each > queue created. > > I'm not aware of anything that is sensitive to the current format of the > bridge queue name, and expects to find a federation uuid in the name. > > -K > > > This addresses bug qpid-3773. > https://issues.apache.org/jira/browse/qpid-3773 > > > Diffs > ----- > > /trunk/qpid/cpp/src/qpid/broker/Bridge.cpp 1233125 > > Diff: https://reviews.apache.org/r/3560/diff > > > Testing > ------- > > > Thanks, > > Kenneth > >
