> On June 16, 2014, 4:29 p.m., Alan Conway wrote:
> > Unfortunately proton and dispatch both use '#' to mean something different.
> > Subscribing to '#' invokes the AMQP 1.0 "dynamic address" feature.
> >
> > proton-c/src/messenger/messenger.c:1545: if (pn_streq(name, "#")) {
> >
> > This is sort of but not exactly like the use of # to generate UUIDs in
> > qpid. It does create a unique and temporary address but using an AMQP 1.0
> > specific mechanism, whereas the qpid # -> UUID works over 0-10 as well.
> >
> > I'm not sure we want to add the UUID feature to proton, but we probably do
> > want the # convention to work sensibly and consistently across the various
> > clients & brokers - i.e. it always means "make me a temporary address" and
> > works consistently regardless of whether it is using AMQP 1.0 dynamic
> > addresses or UUIDs over 0-10 as the implementation. Needs thought.
> >
>
> Pavel Moravec wrote:
> The fix is in native Python client, i.e. AMQP 0-10 relevant only. Where
> the aim is to make Python client to behave like C++ client (over 0-10).
>
> For me, I don't see a big issue from 0-10 providing a different temporary
> node name than 1.0 does so. Till a client requesting such an address is able
> to get the node name via proper API, the client does not care what the name
> looks like - I suppose.
I agree.
- Alan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22630/#review45768
-----------------------------------------------------------
On June 16, 2014, 12:35 p.m., Pavel Moravec wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22630/
> -----------------------------------------------------------
>
> (Updated June 16, 2014, 12:35 p.m.)
>
>
> Review request for qpid, Alan Conway, Gordon Sim, Kenneth Giusti, and Rafael
> Schloming.
>
>
> Bugs: QPID-5823
> https://issues.apache.org/jira/browse/QPID-5823
>
>
> Repository: qpid
>
>
> Description
> -------
>
> The easiest "solution" would be to do the "mangling" in parse_address method
> in driver.py (see original https://svn.apache.org/r1602820 I reverted). That
> prevents any application to get proper node address ('#' expanded).
>
> So the '#' expansion needs to be done in endpoints.py and the information
> "address is expanded" needs to be passed to parse_address method. Either
> using [Sender|Receiver].mangled boolean (like in attached patch) or
> Sender.target / Receiver.source could be a double (address_string, mangled),
> like _mangle method returns in the patch. I don't know what approach (or some
> combination) is better.
>
>
> FYI C++ client has similar code:
>
> if (qpid::messaging::AddressImpl::isTemporary(a) &&
> createPolicy.isVoid()) {
> createPolicy = "always";
> Opt specified = Opt(a)/NODE/X_DECLARE;
> if (!specified.hasKey(AUTO_DELETE)) autoDelete = true;
> if (!specified.hasKey(EXCLUSIVE)) exclusive = true;
> }
>
> where isTemporary(a)==true iff node name starts with '#'.
>
>
> Diffs
> -----
>
> /trunk/qpid/python/qpid/messaging/driver.py 1602841
> /trunk/qpid/python/qpid/messaging/endpoints.py 1602841
>
> Diff: https://reviews.apache.org/r/22630/diff/
>
>
> Testing
> -------
>
> Automated tests passed.
>
> Manual test passed as well:
>
> $ drain "#q; {node: {durable:true}}" -t 2 & qpid-stat -q
> [1] 25174
> c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q; {node: {durable:true}}
> Queues
> queue dur autoDel excl msg msgIn
> msgOut bytes bytesIn bytesOut cons bind
>
> =========================================================================================================================
> af192c4d-b2a0-47c3-8dd4-e99f400da51d:0.0 Y Y 0 0
> 0 0 0 0 1 2
> c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q Y Y Y 0 0
> 0 0 0 0 1 1
> $
>
> (the same for spout)
>
> receiver / producer is able to print expanded address (see the
> "c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q; {node: {durable:true}}" line).
>
>
> Thanks,
>
> Pavel Moravec
>
>
