qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway" <acon...@redhat.com>
Subject Re: Review Request 22630: [QPID-5823]: Python client should create a node with name starting '#'
Date Wed, 02 Jul 2014 14:00:04 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message