On Mon, Sep 19, 2011 at 2:04 PM, Jakub Scholz <[email protected]> wrote: > OK, JIRA QPID-3494 entered. In your opinion, should the lines of code > overwriting the exclusive and auto-delete options be removed or > replaced by different behaviour? > > I can try to prepare a patch ... although preparing a patch for > deleting two lines may be little bit excesive :-)
Jakub, sorry for the late reply. Catching up with the user list now :) First of all thanks for raising this JIRA. I have done some work on the addressing code to address a few issues, including the one you raised. The code you refer to will no not be there once the patch is applied. The time frame for this fix is the upcoming 0.14 release. > Regards > Jakub > > On Mon, Sep 19, 2011 at 19:31, Gordon Sim <[email protected]> wrote: >> On 09/19/2011 06:16 PM, Jakub Scholz wrote: >>> >>> The use case ... is complicated :-). We use the temporary queues in >>> request-response pattern for responses. We wanted to allow the clients >>> to connect with several applications using one account and still use >>> easily the request-response pattern ... i.e. without using the same >>> queue from multiple applications. If we preconfigure the queues, we >>> will not know how many queues to create for each client account. That >>> worked fine, because if you want one queue per application, you don't >>> mind the exclusivity. However last week we got into a problem, because >>> one of our 3rd party servers isn't supporting a proper use of the >>> ReplyTo property when responding to requests. Instead, it is able to >>> send the answer only to one specific destination. Till it is fixed in >>> the 3rd party server, we tried to share one queue between applications >>> and that's how we found the problem. I hope this use case description >>> is understandable ... :-o >> >> Yes it does, thanks for taking the time to explain! >>> >>> I'm not sure about the shorthands ... I personally would prefer more >>> complex description which really does what I want instead of having >>> some shortcuts. >> >> Yes, I understand. The current syntax is intended to give more or less >> complete control over the AMQP 0-10 mapping. >> >> Shorthands was probably also the wrong word. What I mean is that the >> addressing is intended to be a protocol neutral way of declaratively >> describing message sources and targets. Where complex address strings are >> needed, we likely want to abstract the core purpose so that it can be >> expressed more simply and mapped automatically to the correct protocol >> version. >> >>> I was also thinking about compiling some "example" >>> addresses for the most used situations >>> >>> Since the attributes are supported in Python and according to you also >>> in C++, I will enter an JIRA to get this fixed also in Java ... >> >> Marvellous, thank you! >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
