Re: Does broker federation work with azure service bus?

[smartdog]

Thanks for the reply. Would you please elaborate more as both support amqp
1.0?



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Does-broker-federation-work-with-azure-service-bus-tp7605140p7605145.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Does broker federation work with azure service bus?

[Steve Huston]

It won't work.

-Steve

> On Mar 4, 2014, at 9:18 PM, "smartdog"  wrote:
> 
> We need post some messages to Azure Service Bus and figure it would be nice
> (in case Azure service bus is down) to post messages to the local qpid
> broker first and then let the broker propagate messages to Azure. 
> 
> I tried with 
> 
> qpid-route -d queue add azureuser/passw...@namespace.servicebus.windows.net
> 127.0.0.1:5672 amq.fanout brokerqueue 
> 
> and got Failed: VersionError - client: 0-10, server: 0-0 
> 
> It seems related with version conflict (Azure supports amqp 1.0, while
> broker is amqp 0-10) 
> 
> Any idea or this just won't work? Thanks. 
> 
> 
> 
> --
> View this message in context: 
> http://qpid.2158936.n2.nabble.com/Does-broker-federation-work-with-azure-service-bus-tp7605140.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Does broker federation work with azure service bus?

[smartdog]

We need post some messages to Azure Service Bus and figure it would be nice
(in case Azure service bus is down) to post messages to the local qpid
broker first and then let the broker propagate messages to Azure. 

I tried with 

qpid-route -d queue add azureuser/passw...@namespace.servicebus.windows.net
127.0.0.1:5672 amq.fanout brokerqueue 

and got Failed: VersionError - client: 0-10, server: 0-0 

It seems related with version conflict (Azure supports amqp 1.0, while
broker is amqp 0-10) 

Any idea or this just won't work? Thanks. 



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Does-broker-federation-work-with-azure-service-bus-tp7605140.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: QPID C++ broker monitoring and management

[Robbie Gemmell]

It would need to be done ad-hoc at present, the steps we use to generate
and deploy the maven artifacts using the Ant build for the components in
the main Java tree wont really work with the QMF bits because of the
differing layout and build they use.

This is something we will need to look at eventually as part of integrating
with the work being done on a Maven build for the main Java tree currently,
and especially as we then look to split the tree up going beyond that.
Unfortunately it will be a more involved process with the QMF bits as
unlike the main tree we will need to completely reorganise the existing
stuff in order to create a useful Maven build for them, so it wasn't
something I got to in my initial work or which Andrew has looked at yet in
continuing with it.

Robbie

On 4 March 2014 21:49, Jakub Scholz  wrote:

> It would be also nice to have the Java QMF library uploaded to Maven
> repositories similarly to the Java client. But I`m not sure how complicated
> that would be.
>
> Thanks & Regards
> Jakub
>
>
> On Tue, Mar 4, 2014 at 10:25 PM, Gordon Sim  wrote:
>
> > On 03/04/2014 06:19 PM, Fraser Adams wrote:
> >
> >> I had *assumed* that because it was was on trunk it would be on a
> >> release - so I'm a bit confused if I'm honest.
> >>
> >> I've just checked and the first branch it's officially in is
> >>
> >> https://svn.apache.org/repos/asf/qpid/branches/0.24/
> >>
> >
> > Sorry, my mistake. As there wasn't a specific release component for it, I
> > assumed it wasn't released. I tend to overlook the full source bundle as
> I
> > don't use it much myself.
> >
> > Might be nice to have it as a standalone bundle to better highlight that
> > it is available. Also need to update the web site.
> >
> >
> >  Which is what I'd expect, not really sure what the score is with
> >> releases, I tend to build from source.
> >>
> >> I looked in the downloads section http://qpid.apache.org/download.html
> >> at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
> >> python stuff in there currently whereas there are ruby and java
> >> subdirectories of tools/src now too.
> >>
> >> Frase
> >>
> >> On 04/03/14 11:39, Gordon Sim wrote:
> >>
> >>> On 03/04/2014 08:48 AM, Jan Bares wrote:
> >>>
>  Is there any GUI based (web based) QPID management tool?
> 
> >>>
> >>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
> >>> offer it in the releases yet (something we can fix soon perhaps,
> >>> Justin, Fraser?), but you can get it from trunk (or any of the release
> >>> branches if you prefer):
> >>>
> >>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
> >>>
> >>>  I was looking at QMF and I have to say I don't understand what this
>  tool doe.
> 
> >>>
> >>> QMF is merely the mechanism that management tools use. It is a
> >>> protocol on top of AMQP for managing things through sending and
> >>> receiving messages of a particular format.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >>> For additional commands, e-mail: users-h...@qpid.apache.org
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: users-h...@qpid.apache.org
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>

Re: QPID C++ broker monitoring and management

[Jakub Scholz]

It would be also nice to have the Java QMF library uploaded to Maven
repositories similarly to the Java client. But I`m not sure how complicated
that would be.

Thanks & Regards
Jakub


On Tue, Mar 4, 2014 at 10:25 PM, Gordon Sim  wrote:

> On 03/04/2014 06:19 PM, Fraser Adams wrote:
>
>> I had *assumed* that because it was was on trunk it would be on a
>> release - so I'm a bit confused if I'm honest.
>>
>> I've just checked and the first branch it's officially in is
>>
>> https://svn.apache.org/repos/asf/qpid/branches/0.24/
>>
>
> Sorry, my mistake. As there wasn't a specific release component for it, I
> assumed it wasn't released. I tend to overlook the full source bundle as I
> don't use it much myself.
>
> Might be nice to have it as a standalone bundle to better highlight that
> it is available. Also need to update the web site.
>
>
>  Which is what I'd expect, not really sure what the score is with
>> releases, I tend to build from source.
>>
>> I looked in the downloads section http://qpid.apache.org/download.html
>> at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
>> python stuff in there currently whereas there are ruby and java
>> subdirectories of tools/src now too.
>>
>> Frase
>>
>> On 04/03/14 11:39, Gordon Sim wrote:
>>
>>> On 03/04/2014 08:48 AM, Jan Bares wrote:
>>>
 Is there any GUI based (web based) QPID management tool?

>>>
>>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
>>> offer it in the releases yet (something we can fix soon perhaps,
>>> Justin, Fraser?), but you can get it from trunk (or any of the release
>>> branches if you prefer):
>>>
>>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>>
>>>  I was looking at QMF and I have to say I don't understand what this
 tool doe.

>>>
>>> QMF is merely the mechanism that management tools use. It is a
>>> protocol on top of AMQP for managing things through sending and
>>> receiving messages of a particular format.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: QPID C++ broker monitoring and management

[Gordon Sim]

On 03/04/2014 06:19 PM, Fraser Adams wrote:

I had *assumed* that because it was was on trunk it would be on a
release - so I'm a bit confused if I'm honest.

I've just checked and the first branch it's officially in is

https://svn.apache.org/repos/asf/qpid/branches/0.24/


Sorry, my mistake. As there wasn't a specific release component for it, 
I assumed it wasn't released. I tend to overlook the full source bundle 
as I don't use it much myself.


Might be nice to have it as a standalone bundle to better highlight that 
it is available. Also need to update the web site.



Which is what I'd expect, not really sure what the score is with
releases, I tend to build from source.

I looked in the downloads section http://qpid.apache.org/download.html
at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
python stuff in there currently whereas there are ruby and java
subdirectories of tools/src now too.

Frase

On 04/03/14 11:39, Gordon Sim wrote:

On 03/04/2014 08:48 AM, Jan Bares wrote:

Is there any GUI based (web based) QPID management tool?


Yes, Fraser Adams built a web based console for QMF. We don't seem to
offer it in the releases yet (something we can fix soon perhaps,
Justin, Fraser?), but you can get it from trunk (or any of the release
branches if you prefer):

https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java


I was looking at QMF and I have to say I don't understand what this
tool doe.


QMF is merely the mechanism that management tools use. It is a
protocol on top of AMQP for managing things through sending and
receiving messages of a particular format.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: QPID C++ broker monitoring and management

[Robbie Gemmell]

It is included in the full source release,
http://www.apache.org/dyn/closer.cgi/qpid/0.26/qpid-0.26.tar.gz , it just
hasn't got its own separate archive.

Robbie

On 4 March 2014 18:19, Fraser Adams  wrote:

> I had *assumed* that because it was was on trunk it would be on a release
> - so I'm a bit confused if I'm honest.
>
> I've just checked and the first branch it's officially in is
>
> https://svn.apache.org/repos/asf/qpid/branches/0.24/
>
> Which is what I'd expect, not really sure what the score is with releases,
> I tend to build from source.
>
> I looked in the downloads section http://qpid.apache.org/download.html at
> qpid-tools-0.26.tar.gz and noticed that this only seems to have the python
> stuff in there currently whereas there are ruby and java subdirectories of
> tools/src now too.
>
> Frase
>
>
> On 04/03/14 11:39, Gordon Sim wrote:
>
>> On 03/04/2014 08:48 AM, Jan Bares wrote:
>>
>>> Is there any GUI based (web based) QPID management tool?
>>>
>>
>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
>> offer it in the releases yet (something we can fix soon perhaps, Justin,
>> Fraser?), but you can get it from trunk (or any of the release branches if
>> you prefer):
>>
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>
>>  I was looking at QMF and I have to say I don't understand what this tool
>>> doe.
>>>
>>
>> QMF is merely the mechanism that management tools use. It is a protocol
>> on top of AMQP for managing things through sending and receiving messages
>> of a particular format.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: QPID C++ broker monitoring and management

[Fraser Adams]

I had *assumed* that because it was was on trunk it would be on a 
release - so I'm a bit confused if I'm honest.


I've just checked and the first branch it's officially in is

https://svn.apache.org/repos/asf/qpid/branches/0.24/

Which is what I'd expect, not really sure what the score is with 
releases, I tend to build from source.


I looked in the downloads section http://qpid.apache.org/download.html 
at qpid-tools-0.26.tar.gz and noticed that this only seems to have the 
python stuff in there currently whereas there are ruby and java 
subdirectories of tools/src now too.


Frase

On 04/03/14 11:39, Gordon Sim wrote:

On 03/04/2014 08:48 AM, Jan Bares wrote:

Is there any GUI based (web based) QPID management tool?


Yes, Fraser Adams built a web based console for QMF. We don't seem to 
offer it in the releases yet (something we can fix soon perhaps, 
Justin, Fraser?), but you can get it from trunk (or any of the release 
branches if you prefer):


https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java

I was looking at QMF and I have to say I don't understand what this 
tool doe.


QMF is merely the mechanism that management tools use. It is a 
protocol on top of AMQP for managing things through sending and 
receiving messages of a particular format.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: AMQP 1.0 <-> 0-10 reply-to conversion

[Rafael Schloming]

On Tue, Mar 4, 2014 at 8:27 AM, Rob Godfrey  wrote:

> On 4 March 2014 14:11, Gordon Sim  wrote:
>
> > On 03/04/2014 12:38 PM, Rafael Schloming wrote:
> >
> >> On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim  wrote:
> >>
> >>  On 03/04/2014 11:00 AM, Rob Godfrey wrote:
> >>>
> >>>  The naive approach for a 1.0 address "foo" is (I guess) to look up on
>  the
>  broker side to see if the given there is an exchange named "foo" (in
>  which
>  case translate to 0-10 {exchange="foo", routing-key=""}) or a queue
>  named
>  "foo" (in which case translate to a 0-10
> {exchange="",routing-key="foo"
>  ).
> 
> 
> >>> That is what the c++ broker currently does.
> >>>
> >>
> >>
> >> In some ways this makes sense, but it also has some undesirable
> >> properties,
> >> i.e. the translation process from 0-10 to 1-0 address form depends on
> the
> >> internal state of the broker, and that state may change over time.
> >>
> >
> > It's the translation process from 1.0 to 0-10
> >
> >
> >  For
> >> example, say you have a sequence of messages that are initially resolved
> >> to
> >> a queue named "foo", then part way through that sequence someone creates
> >> an
> >> exchange named "foo".
> >>
> >
> > Introducing ambiguity about the node name is I think an explicit
> > alteration of the meaning of the name. It would affect the creation of a
> > link over 1.0 and even the creation of a sender/receiver using the
> > qpid::messaging API over 0-10.
> >
> > It feels top me in the same class of scenario as deleting and recreating
> a
> > node of a given name (though clearly its not exactly the same and is
> easier
> > to do by accident).
> >
> > So at present I'm personally inclined not to worry about this too much,
> > i.e. consider it a corner case and advise people not to do that :-)
> >
> >
> >
> I agree with Gordon here.  Since the messaging API / address stuff
> effectively merged the domain of queue names and exchange names, that
> ambiguity has existed.  I think it is probably least likely to cause people
> issues if we continue to treat ambiguous addresses in the same way.
>

The issue isn't the ambiguity. The ability to rewire/reconfigure the
routing behaviour associated with a given address by e.g. adding/removing
bindings is exactly the same sort of "ambiguity", but it is considered a
feature not a bug. The issue is *when* you resolve the ambiguity. With the
messaging API that ambiguity is resolved when a sender/receiver is
established to a given address. A broker implementing some kind of
translation has the choice of whether to resolve it upon link establishment
or on a per message basis. With the reply-to translation, however, you are
adding a new resolution point that has previously never existed. It is
roughly analogous to taking a pure 0-x broker with no translation and
deciding to "pre-route" the reply based on which bindings match the
reply-to as the request goes through the broker rather than based on what
bindings exist when the real reply is submitted.

Now I'm not saying that resolving an address to a node should necessarily
happen on a per message basis like matching against bindings does, but it
does strike me that a clean mapping of 1.0 into an 0-x broker will have to
have well defined address resolution semantics both in terms of *when* that
resolution happens as well as *how* it happens, and that IMHO choosing the
point at which a reply-to passes through the broker isn't a very meaningful
time to perform that resolution. In fact in a federated environment, that
point is pretty much an arbitrary and unknowable point in time between when
the reply-to was first set, and when it is finally used.

>
>
>
>
> >  You now have a mix of live messages some of which
> >> have address {exchange="", routing-key="foo"}, and others of which have
> >> {exchange="foo", routing-key=""}. It seems unlikely that the application
> >> would actually want a single stream of messages all sent to the same
> >> address to end up with a mix of semantically different addresses when
> they
> >> come out the other side of the broker.
> >>
> >> One option to consider would be to define a special exchange with a
> >> reserved name that knows how to interpret 1.0 addresses. That would
> allow
> >> you to perform a simple stateless/stable translation of any 1.0 address
> >> into something like {exchange="$amqp1.0", routing-key=""}. This
> >> has the benefit that translated address will always have the same
> semantic
> >> meaning over time. The one drawback is that the address might not work
> as
> >> well with other brokers if they don't recognize the "$amqp1.0" exchange,
> >> however I suspect if the 1-0 reply-to address is ultimately intended
> for a
> >> federated broker, then translating it based on the internal state of its
> >> current broker is not necessarily the right thing either.
> >>
> >
> > Sounds interesting certainly. My main objective was getting simple
> > client-server applications worki

Re: AMQP 1.0 <-> 0-10 reply-to conversion

[Rob Godfrey]

On 4 March 2014 14:11, Gordon Sim  wrote:

> On 03/04/2014 12:38 PM, Rafael Schloming wrote:
>
>> On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim  wrote:
>>
>>  On 03/04/2014 11:00 AM, Rob Godfrey wrote:
>>>
>>>  The naive approach for a 1.0 address "foo" is (I guess) to look up on
 the
 broker side to see if the given there is an exchange named "foo" (in
 which
 case translate to 0-10 {exchange="foo", routing-key=""}) or a queue
 named
 "foo" (in which case translate to a 0-10 {exchange="",routing-key="foo"
 ).


>>> That is what the c++ broker currently does.
>>>
>>
>>
>> In some ways this makes sense, but it also has some undesirable
>> properties,
>> i.e. the translation process from 0-10 to 1-0 address form depends on the
>> internal state of the broker, and that state may change over time.
>>
>
> It's the translation process from 1.0 to 0-10
>
>
>  For
>> example, say you have a sequence of messages that are initially resolved
>> to
>> a queue named "foo", then part way through that sequence someone creates
>> an
>> exchange named "foo".
>>
>
> Introducing ambiguity about the node name is I think an explicit
> alteration of the meaning of the name. It would affect the creation of a
> link over 1.0 and even the creation of a sender/receiver using the
> qpid::messaging API over 0-10.
>
> It feels top me in the same class of scenario as deleting and recreating a
> node of a given name (though clearly its not exactly the same and is easier
> to do by accident).
>
> So at present I'm personally inclined not to worry about this too much,
> i.e. consider it a corner case and advise people not to do that :-)
>
>
>
I agree with Gordon here.  Since the messaging API / address stuff
effectively merged the domain of queue names and exchange names, that
ambiguity has existed.  I think it is probably least likely to cause people
issues if we continue to treat ambiguous addresses in the same way.



>  You now have a mix of live messages some of which
>> have address {exchange="", routing-key="foo"}, and others of which have
>> {exchange="foo", routing-key=""}. It seems unlikely that the application
>> would actually want a single stream of messages all sent to the same
>> address to end up with a mix of semantically different addresses when they
>> come out the other side of the broker.
>>
>> One option to consider would be to define a special exchange with a
>> reserved name that knows how to interpret 1.0 addresses. That would allow
>> you to perform a simple stateless/stable translation of any 1.0 address
>> into something like {exchange="$amqp1.0", routing-key=""}. This
>> has the benefit that translated address will always have the same semantic
>> meaning over time. The one drawback is that the address might not work as
>> well with other brokers if they don't recognize the "$amqp1.0" exchange,
>> however I suspect if the 1-0 reply-to address is ultimately intended for a
>> federated broker, then translating it based on the internal state of its
>> current broker is not necessarily the right thing either.
>>
>
> Sounds interesting certainly. My main objective was getting simple
> client-server applications working when the two parties were using
> different protocols (but the same broker). I'm sure more sophisticated
> schemes can be constructed if/when someone has sufficient need and/or
> desire.
>
>
>
To be honest I am going to treat the "default" exchange like this... i.e.
it will resolve anything it sees in the routing key of a message sent to it
in the same was the AMQP 1.0 interface will treat an address sent to the
routing node.  However this in itself doesn't resolve the ambiguity about
"foo" because where foo routes to is dependent upon whether there is an
exchange, a queue or both.  (In practice this may be a small violation of
the 0-x spec as things will route even if the routing key doesn't represent
a queue... however given the broker is opening up all sort of possibilities
for nodes which are no longer queues nor exchanges, I am happy with this
violation).

-- Rob


>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: AMQP 1.0 <-> 0-10 reply-to conversion

[Gordon Sim]

On 03/04/2014 12:38 PM, Rafael Schloming wrote:

On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim  wrote:


On 03/04/2014 11:00 AM, Rob Godfrey wrote:


The naive approach for a 1.0 address "foo" is (I guess) to look up on the
broker side to see if the given there is an exchange named "foo" (in which
case translate to 0-10 {exchange="foo", routing-key=""}) or a queue named
"foo" (in which case translate to a 0-10 {exchange="",routing-key="foo").



That is what the c++ broker currently does.



In some ways this makes sense, but it also has some undesirable properties,
i.e. the translation process from 0-10 to 1-0 address form depends on the
internal state of the broker, and that state may change over time.


It's the translation process from 1.0 to 0-10


For
example, say you have a sequence of messages that are initially resolved to
a queue named "foo", then part way through that sequence someone creates an
exchange named "foo".


Introducing ambiguity about the node name is I think an explicit 
alteration of the meaning of the name. It would affect the creation of a 
link over 1.0 and even the creation of a sender/receiver using the 
qpid::messaging API over 0-10.


It feels top me in the same class of scenario as deleting and recreating 
a node of a given name (though clearly its not exactly the same and is 
easier to do by accident).


So at present I'm personally inclined not to worry about this too much, 
i.e. consider it a corner case and advise people not to do that :-)



You now have a mix of live messages some of which
have address {exchange="", routing-key="foo"}, and others of which have
{exchange="foo", routing-key=""}. It seems unlikely that the application
would actually want a single stream of messages all sent to the same
address to end up with a mix of semantically different addresses when they
come out the other side of the broker.

One option to consider would be to define a special exchange with a
reserved name that knows how to interpret 1.0 addresses. That would allow
you to perform a simple stateless/stable translation of any 1.0 address
into something like {exchange="$amqp1.0", routing-key=""}. This
has the benefit that translated address will always have the same semantic
meaning over time. The one drawback is that the address might not work as
well with other brokers if they don't recognize the "$amqp1.0" exchange,
however I suspect if the 1-0 reply-to address is ultimately intended for a
federated broker, then translating it based on the internal state of its
current broker is not necessarily the right thing either.


Sounds interesting certainly. My main objective was getting simple 
client-server applications working when the two parties were using 
different protocols (but the same broker). I'm sure more sophisticated 
schemes can be constructed if/when someone has sufficient need and/or 
desire.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: AMQP 1.0 <-> 0-10 reply-to conversion

[Rafael Schloming]

On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim  wrote:

> On 03/04/2014 11:00 AM, Rob Godfrey wrote:
>
>> The naive approach for a 1.0 address "foo" is (I guess) to look up on the
>> broker side to see if the given there is an exchange named "foo" (in which
>> case translate to 0-10 {exchange="foo", routing-key=""}) or a queue named
>> "foo" (in which case translate to a 0-10 {exchange="",routing-key="foo").
>>
>
> That is what the c++ broker currently does.


In some ways this makes sense, but it also has some undesirable properties,
i.e. the translation process from 0-10 to 1-0 address form depends on the
internal state of the broker, and that state may change over time. For
example, say you have a sequence of messages that are initially resolved to
a queue named "foo", then part way through that sequence someone creates an
exchange named "foo". You now have a mix of live messages some of which
have address {exchange="", routing-key="foo"}, and others of which have
{exchange="foo", routing-key=""}. It seems unlikely that the application
would actually want a single stream of messages all sent to the same
address to end up with a mix of semantically different addresses when they
come out the other side of the broker.

One option to consider would be to define a special exchange with a
reserved name that knows how to interpret 1.0 addresses. That would allow
you to perform a simple stateless/stable translation of any 1.0 address
into something like {exchange="$amqp1.0", routing-key=""}. This
has the benefit that translated address will always have the same semantic
meaning over time. The one drawback is that the address might not work as
well with other brokers if they don't recognize the "$amqp1.0" exchange,
however I suspect if the 1-0 reply-to address is ultimately intended for a
federated broker, then translating it based on the internal state of its
current broker is not necessarily the right thing either.

--Rafael

Re: AMQP 1.0 <-> 0-10 reply-to conversion

[Gordon Sim]

On 03/04/2014 11:00 AM, Rob Godfrey wrote:

The naive approach for a 1.0 address "foo" is (I guess) to look up on the
broker side to see if the given there is an exchange named "foo" (in which
case translate to 0-10 {exchange="foo", routing-key=""}) or a queue named
"foo" (in which case translate to a 0-10 {exchange="",routing-key="foo").


That is what the c++ broker currently does.


However what if there is neither an exchange nor a queue named foo...


The c++ broker currently doesn't set an 0-10 reply to in that case.


In the opposite direction if you have an 0-10 address
{exchange="foo",routing-key="bar"} how do we translate that into a 1-0
address.


The c++ broker will convert that to a reply-to of 'foo/bar' on the 1.0 
message.



Does the C++ broker have an answer for this yet?

My current train of thought is that I'll translate 1-0 addresses of the
form "foo/bar" into exchange="foo", routing-key="bar" (and will also treat
1.0 links to destinations of that form accordingly).  Addresses which begin
with a "/" will be treated as AMQP Global addresses (per the emerging
specs)... for conversion to 0-10 purposes that will be the no-name exchange
and the address will go into the routing key.


That is essentially what the c++ broker does, except that as yet it 
doesn't support the same logic in resolving links (though I agree it may 
make sense to do so).



Addresses with no "/" will be treated as a queue - unless there is no queue
in which case it will fall back to looking for an exchange


That's what the c++ broker does.


(this is the
Java Broker's default behaviour for any address)... Where there is no queue
or exchange the reply-to conversion will treat it as per a global address
{exchange="",routing-key=address}.


As above, in this case I don't set a reply-to at all.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: QPID C++ broker monitoring and management

[Gordon Sim]

On 03/04/2014 08:48 AM, Jan Bares wrote:

Is there any GUI based (web based) QPID management tool?


Yes, Fraser Adams built a web based console for QMF. We don't seem to 
offer it in the releases yet (something we can fix soon perhaps, Justin, 
Fraser?), but you can get it from trunk (or any of the release branches 
if you prefer):


https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java


I was looking at QMF and I have to say I don't understand what this tool doe.


QMF is merely the mechanism that management tools use. It is a protocol 
on top of AMQP for managing things through sending and receiving 
messages of a particular format.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

AMQP 1.0 <-> 0-10 reply-to conversion

[Rob Godfrey]

I'm currently trying to tidy up some of the message conversion code inside
the Java Broker, and wondering what the correct approach is with reply-to.

In 1.0 the reply-to address is a simple string (which may have some
structure when the OASIS Addressing spec is finalised, but until now can
really be thought of as opaque).

In 0-10 the reply-to consists of an exchange and a routing-key pair...
(which means that if you want to reply to a given queue you can use the
default no-name exchange, and the queue name as the routing key).

The naive approach for a 1.0 address "foo" is (I guess) to look up on the
broker side to see if the given there is an exchange named "foo" (in which
case translate to 0-10 {exchange="foo", routing-key=""}) or a queue named
"foo" (in which case translate to a 0-10 {exchange="",routing-key="foo").
However what if there is neither an exchange nor a queue named foo...

In the opposite direction if you have an 0-10 address
{exchange="foo",routing-key="bar"} how do we translate that into a 1-0
address.

Does the C++ broker have an answer for this yet?

My current train of thought is that I'll translate 1-0 addresses of the
form "foo/bar" into exchange="foo", routing-key="bar" (and will also treat
1.0 links to destinations of that form accordingly).  Addresses which begin
with a "/" will be treated as AMQP Global addresses (per the emerging
specs)... for conversion to 0-10 purposes that will be the no-name exchange
and the address will go into the routing key.

Addresses with no "/" will be treated as a queue - unless there is no queue
in which case it will fall back to looking for an exchange (this is the
Java Broker's default behaviour for any address)... Where there is no queue
or exchange the reply-to conversion will treat it as per a global address
{exchange="",routing-key=address}.

As above, does the C++ broker have a better answer already?

-- Rob

QPID C++ broker monitoring and management

[Jan Bares]

Hi,

Which tools do you use for monitoring? I would like to use something like 
Zabbix (www.zabbix.com) for QPID monitoring, should I use the command line tool 
like qpid-stat to gather statistics or is there better option? And what do you 
monitor? This pops out of my mind (besides log):
* lingering messages in queue (e.g. consumer is dead)
* messages in dead letter queue
* number of messages over time period

Is there any GUI based (web based) QPID management tool? I was looking at QMF 
and I have to say I don't understand what this tool doe. It seems like Java's 
JMX or other management tools without ready to use agents or GUI. Did not found 
any documentation of console.py in the QMF download.

Thank you for your time, Jan

Jan Bareš
Calypso Lead Developer

In association with
WOOD & Company Financial Services, a.s.
Palladium, Náměstí Republiky 1079/1a
110 00 Prague, Czech Republic
Tel. +420 222 096 111
Direct +420 222 096 457
Fax. +420 222 096 222





DISCLAIMER

 WOOD & Company Financial Services, a.s. and its branches are 
authorized and regulated by the CNB as Home State regulator and in Poland by 
the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State 
regulators. For further information about WOOD & Co., its investment services, 
financial instruments and associated risks, safeguard client assets (incl. 
compensation schemes) and contractual relationship please see our website at 
www.wood.com under section Corporate Governance.
 Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. All estimates, 
opinions and other information contained herein are subject to change without 
notice and are provided in good faith but without legal responsibility or 
liability. Opinion may be personal to the author and may not reflect the 
opinions of WOOD & Co. Communications from sales persons, sales traders or 
traders should not be regarded as investment research and may contain opinions 
or trading ideas which are different from WOOD & Co. investment research 
opinions.
 This e-mail and any attachments are confidential and may be privileged 
or otherwise protected from disclosure. If you are not a named addressee you 
must not use, disclose, distribute, copy, print or rely on this e-mail and any 
of its attachments. Please notify the sender that you have received this email 
by mistake by replying to the email, and then delete the email and any copies 
of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees 
should scan this e-mail and any attachments for viruses. WOOD & Co. makes no 
representation or warranty as to the absence of viruses in this e-mail or any 
attachments. Please note that to ensure regulatory compliance and for the 
protection of our clients and business, we may monitor and read e-mails sent to 
and from our server(s).


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org