Re: Documentation of C++ Messaging connection URL?
On Fri, 2014-02-07 at 16:48 +, Fraser Adams wrote:
> ... TBH I mainly mentioned it because when I was going
> through my exercise of trying out various AMQP 1.0 subscribers I was
> starting to find the:
>
> --connection-options {protocol:amqp1.0}
>
> A little bit less aesthetically pleasing than the sort of
>
> amqp://localhost:5672
>
The issue here is which protocol the client initiates the connection
with. Really what would be most convenient would be for the client to
try 1.0 and if it fails to try 0-10.
However, due to the way that protocol switching works, the client can't
easily do this (by the time we get the protocol rejection we're in the
specific 0-10 or 1.0 implementation already).
So I think you could regard the "protocol" connection option as a hint
of which protocol to try, and in a better implementation it would not be
needed at all.
Also I think it would be fair that in a future release the default might
switch from 0-10 to 1.0 when that becomes the most implemented protocol
version.
Andrew
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Documentation of C++ Messaging connection URL?
> From: "Fraser Adams" > Sent: Friday, February 7, 2014 10:43:06 AM > Note that for qpid::messaging this stuff is all in the connection > options, the actual "URL" is usually just set as just a basic > :, though actually I *think* that it is an AMQP 0.10 URL and > you can actually do amqp:: though TBH I'm not sure if anyone > does. > Apache NMS uses the amqp: form exclusively. The amqp: is what steers the request to the AMQP Provider and it sends the string to Messaging unmodified. NMS Provider handles AMQP Domain:connection.amqp-host-url host specs including alternate hosts. The big question I wanted to settle was if there were any options possibly embedded in the connection URI/URL. It's hard to write that these may work without actually trying them. Getting this right saves me from spreading misinformation. Thanks for your thoughts. -Chuck - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Documentation of C++ Messaging connection URL?
On 07/02/14 16:00, Gordon Sim wrote:
On 02/07/2014 03:43 PM, Fraser Adams wrote:
I do rather wonder that for AMQP 1.0 if the URL could be improved to
accept something like:
amqp://[][:@][:][:]
I think for consistency it would be better to drop the part
and use amqp/amqps as the scheme there.
By proto in this case I was thinking of say an alternative transport
like sctp or infiniband or suchlike e.g.
amqp://guest:guest@sctp:localhost:5672
I'm *mostly* just thinking along the lines of how one could make this
part of the address the same as say Proton Messenger as I think that the
closer qpid::messaging and Proton Messenger Addresses look
(notwithstanding differences borne out by one being connection oriented
and the other message oriented) then ultimately the less confusing it's
likely to be for users.
There's clearly also the Java ConnectinURL to consider too, but again
from my perspective I'd quite like the maximum amount of cohesion - I'm
a bit simple minded and easy to confuse :-D
Which would make it look more like the first part of the Proton
Messenger style Address and because the amqp:// would distinguish it
from the AMQP 0.10 style URL you could use it instead of the
protocol/user/password connection options to signify AMQP 1.0.
I don't object to accepting urls of the form above, but I don't like
the idea of using them to imply protocol version. The same scheme is
used by many things (including the qpid.messaging python client) for
earlier versions.
when you say the same scheme do you mean that the python client uses
"amqp://"?
Fair enough comment. TBH I mainly mentioned it because when I was going
through my exercise of trying out various AMQP 1.0 subscribers I was
starting to find the:
--connection-options {protocol:amqp1.0}
A little bit less aesthetically pleasing than the sort of
amqp://localhost:5672
Addresses I was using with Messenger, so I was idly wondering if there
was a way to specify addresses of the same form on qpid::messaging so I
could avoid needing explicit connection options for being AMQP 1.0 and
the user/password stuff
If the amqp:// prefix isn't unambiguously 1.0 then I take your point, I
had assumed that the URL was either : or amqp::
in which case amqp:// would have been different.
Cheers,
Frase
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Documentation of C++ Messaging connection URL?
On 02/07/2014 03:43 PM, Fraser Adams wrote: I do rather wonder that for AMQP 1.0 if the URL could be improved to accept something like: amqp://[][:@][:][:] I think for consistency it would be better to drop the part and use amqp/amqps as the scheme there. Which would make it look more like the first part of the Proton Messenger style Address and because the amqp:// would distinguish it from the AMQP 0.10 style URL you could use it instead of the protocol/user/password connection options to signify AMQP 1.0. I don't object to accepting urls of the form above, but I don't like the idea of using them to imply protocol version. The same scheme is used by many things (including the qpid.messaging python client) for earlier versions. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Documentation of C++ Messaging connection URL?
Hi Chuck,
I think that the
http://qpid.apache.org/releases/qpid-0.24/programming/book/connection-options.html
book is indeed where most people would tend to look, but it's not quite
complete
The qpid::messaging API doxygen docs
http://qpid.apache.org/releases/qpid-0.24/messaging-api/cpp/api/classqpid_1_1messaging_1_1Connection.html
(which mentions a few more things than the "programming" book) says:
Current implementation supports the following options:
* heartbeat: the heartbeat interval in seconds
* tcp_nodelay: true/false, whether nagle should be disabled or not
* transport: the underlying transport to use (e.g. tcp, ssl, rsdma)
* protocol: the version of AMQP to use (e.g. amqp0-10 or amqp1.0)
(Note: the transports and/or protocols recognised may depend on which
plugins are loaded)
* username: the username to authenticate as
* password: the password to use if required by the selected
authentication mechanism
* sasl_mechanisms: a space separated list of acceptable SASL mechanisms
* sasl_min_ssf: the minimum acceptable security strength factor
* sasl_max_ssf: the maximum acceptable security strength factor
* sasl_service: the service name if needed by the SASL mechanism in use
Reconnect behaviour can be controlled through the following options:
* reconnect: true/false (enables/disables reconnect entirely)
* reconnect_timeout: seconds (give up and report failure after
specified time)
* reconnect_limit: n (give up and report failure after specified
number of attempts)
* reconnect_interval_min: seconds (initial delay between failed
reconnection attempts)
* reconnect_interval_max: seconds (maximum delay between failed
reconnection attempts)
* reconnect_interval: shorthand for setting the same
reconnect_interval_min/max
* reconnect_urls: list of alternate urls to try when connecting
The reconnect_interval is the time that the client waits for after a
failed attempt to reconnect before retrying. It starts at the value of
the min_retry_interval and is doubled every failure until the value of
max_retry_interval is reached.
Values in seconds can be fractional, for example 0.001 is a millisecond
delay.
It's worth also mentioning that (for AMQP 1.0 at any rate) even the
doxygen stuff seems incompete if you look in
/qpid-trunk/qpid/cpp/src/qpid/messaging/ConnectionOptions.cpp
there are a few additional fields.
void ConnectionOptions::set(const std::string& name, const
qpid::types::Variant& value)
{
if (name == "reconnect") {
reconnect = value;
} else if (name == "reconnect-timeout" || name ==
"reconnect_timeout") {
timeout = timeValue(value);
} else if (name == "reconnect-limit" || name == "reconnect_limit") {
limit = value;
} else if (name == "reconnect-interval" || name ==
"reconnect_interval") {
maxReconnectInterval = minReconnectInterval = timeValue(value);
} else if (name == "reconnect-interval-min" || name ==
"reconnect_interval_min") {
minReconnectInterval = timeValue(value);
} else if (name == "reconnect-interval-max" || name ==
"reconnect_interval_max") {
maxReconnectInterval = timeValue(value);
} else if (name == "reconnect-urls-replace" || name ==
"reconnect_urls_replace") {
replaceUrls = value.asBool();
} else if (name == "reconnect-urls" || name == "reconnect_urls") {
if (replaceUrls) urls.clear();
if (value.getType() == qpid::types::VAR_LIST) {
merge(value.asList(), urls);
} else {
merge(value.asString(), urls);
}
} else if (name == "username") {
username = value.asString();
} else if (name == "password") {
password = value.asString();
} else if (name == "sasl-mechanism" || name == "sasl_mechanism" ||
name == "sasl-mechanisms" || name == "sasl_mechanisms") {
mechanism = value.asString();
} else if (name == "sasl-service" || name == "sasl_service") {
service = value.asString();
} else if (name == "sasl-min-ssf" || name == "sasl_min_ssf") {
minSsf = value;
} else if (name == "sasl-max-ssf" || name == "sasl_max_ssf") {
maxSsf = value;
} else if (name == "heartbeat") {
heartbeat = value;
} else if (name == "tcp-nodelay" || name == "tcp_nodelay") {
tcpNoDelay = value;
} else if (name == "locale") {
locale = value.asString();
} else if (name == "max-channels" || name == "max_channels") {
maxChannels = value;
} else if (name == "max-frame-size" || name == "max_frame_size") {
maxFrameSize = value;
} else if (name == "bounds") {
bounds = value;
} else if (name == "transport") {
protocol = value.asString();
} else if (name == "ssl-cert-name" || name == "ssl_cert_name") {
sslCertName = value.asString();
} else if (name == "x-reconnect-on-limit-exceeded" || name ==
"x_reconnect_on_limit_exceeded") {
reco
Re: Documentation of C++ Messaging connection URL?
On 02/07/2014 03:00 PM, Chuck Rolke wrote: I'm writing a how-to document for the Apache.NMS.AMQP Provider (a .NET subsystem to provide AMQP support to http://activemq.apache.org/nms/). I'm looking for a pointer to a description of the C++ Messaging API connection URL. The C++ connection options are easy enough to find: http://qpid.apache.org/releases/qpid-0.24/programming/book/connection-options.html The JMS Connection URL is declared at: http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJNDI.html#section-jms-connection-url I suspect that the C++ connection URL is similar if not identical to the JMS connection URL. No, its not. The c++ messaging API accepts two types of 'url', the first is as described in the 0-10 specification. The second is a simple host:port form for convenience. Also the parser is more lenient that the formal 0-10 grammar iirc, and some thinks are considered optional in practice (again for convenience). However, if one or more fields are different or absent then this assumption is no good. Can anyone confirm this for me or point me to a description? The C++ Messaging API needs a section as clear and direct as the JMS connection URL page. I'll be happy to add that going forward. Thanks, Chuck - 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
Documentation of C++ Messaging connection URL?
I'm writing a how-to document for the Apache.NMS.AMQP Provider (a .NET subsystem to provide AMQP support to http://activemq.apache.org/nms/). I'm looking for a pointer to a description of the C++ Messaging API connection URL. The C++ connection options are easy enough to find: http://qpid.apache.org/releases/qpid-0.24/programming/book/connection-options.html The JMS Connection URL is declared at: http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJNDI.html#section-jms-connection-url I suspect that the C++ connection URL is similar if not identical to the JMS connection URL. However, if one or more fields are different or absent then this assumption is no good. Can anyone confirm this for me or point me to a description? The C++ Messaging API needs a section as clear and direct as the JMS connection URL page. I'll be happy to add that going forward. Thanks, Chuck - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid website update
Great! Thanks! -Steve > On Feb 7, 2014, at 7:38 AM, "Justin Ross" wrote: > >> On Tue, Feb 4, 2014 at 4:23 PM, Steve Huston wrote: >> On the Contributors page, in thanks section, it would be good to mention >> Coverity for allowing us use of Coverity Scan to do static analysis. > > You're right, of course! I've added them to the companies section of > the contributors page: > > http://people.apache.org/~jross/transom/head/contributors.html#companies > > Justin > > - > 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 website update
On Wed, Feb 5, 2014 at 10:58 AM, Gordon Sim wrote: > On 02/05/2014 03:51 PM, Alan Conway wrote: >> >> I never noticed "developer central" before - very handy set of >> shortcuts! > > Indeed! I would think this was useful to users and developers alike. Could > we make it more prominent somehow? It's somewhat more prominent on the existing site (before this update lands). That doesn't seem to have been enough to get it noticed. If we want to broaden the audience of this "useful things, all in one place", I think it should have a new name, and that might point the way to figuring out how we promote it. "Develop*ment* Center" would be a little better. "Mission control" is the right idea, but it's used a lot. Once it has a theme and its scope is resolved, I can use a graphic to draw more attention to it. Side note on audience: The vast majority of the Qpid site is, naturally enough, geared toward users. It prioritizes the information and resources you need to (a) evaluate Qpid and (b) use Qpid to build your own applications. This necessarily meant that developer priorities got pushed down a little. I created the developer center to set aside a place to focus on what Qpid developers need most. I personally keep it bookmarked so I can quickly jump to jiras and link to posts in the archives, etc. Justin - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid website update
On Tue, Feb 4, 2014 at 4:23 PM, Steve Huston wrote: > On the Contributors page, in thanks section, it would be good to mention > Coverity for allowing us use of Coverity Scan to do static analysis. You're right, of course! I've added them to the companies section of the contributors page: http://people.apache.org/~jross/transom/head/contributors.html#companies Justin - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Message API - Real world usage issue
On 06/02/14 19:07, CLIVE wrote:
Hi,
[snip]
The first use case requires the dynamic creation of Receivers, but
before creating a new receiver, I would like to know if I already have
a receiver that would match the required binding. This is not possible
at the moment because the binding matching algorithms are hidden from
public view; they are buried deep inside the Brokers Exchange
Implementation code.
You know that you can get the binding information from QMF don't you
Clive? I guess I'm missing what you're looking for if it's something
different than that. And I guess to be fair to get the information via
QMF you'd need a bit of code, but I'd have thought that this would be
the most appropriate way to get the information.
Out of curiosity why do you need to know if you already have a receiver
that would match the binding?
One thing that's worth mentioning, I'm suspecting that (like me) you've
mainly been using AMQP 0.10 - If I'm reading you correctly you sound
like you are dynamically creating queue nodes and passing x-bindings.
I've been doing that for a few years, but a few weeks back I started
looking at AMQP 1.0 and that primarily takes a perspective of addressing
the topic like exchanges and the queues end up being subscription queues
and all of the stuff that relates to binding and the like ends up in the
link (not node) config.
For me at any rate that was quite a different perspective on things (I
wrote up what I was up to in the "A write up of some AMQP 1.0
Experiments" post) previously I've been focussing on the queues, so I
was dynamically creating queue nodes and passing x-bindings in AMQP
0.10, but in AMQP 1.0 I've been addressing the exchanges (topic type
nodes) and using the link to specify what I need. For me it took a bit
of getting used to because I was so ingrained doing it the other way,
but I think I'm getting it now.
The second use case in question requires a client application to
dynamically create multiple receivers for the same queue, but with
slightly different binding keys bound to an exchange. When a message
from an exchange gets put in the queue and delivered to the client
(via a receiver)
I'm not sure if I'm correctly interpreting what you are saying here, so
you want a client that has a single queue, but each receiver adds
different binding keys right? You do know that this will result in what
amounts to an OR condition - both keys will be bound and a message will
be put on the queue if either match so consumer A of the queue would
receive messages due to consumer B's key - is that what you mean.
The following AMQP 1.0 consumers will do what you seem to be saying,
there's a single shared subscription queue called queue1, the first
consumer binds *.news the second *.weather
./drain --connection-options {protocol:amqp1.0} -b localhost -f \
"amq.topic/*.news; {node: {capabilities: [shared]}, link: {name: queue1}}"
./drain --connection-options {protocol:amqp1.0} -b localhost -f \
"amq.topic/*.weather; {node: {capabilities: [shared]}, link: {name:
queue1}}"
qpid-config -r queues gives
Queue 'queue1'
bind [queue1] => ''
bind [*.news] => amq.topic
bind [*.weather] => amq.topic
For AMQP 0.10 the following would create a similar effect (not sure if
you want auto delete or not, if not remove the x-declare below and for
the AMQP 1.0 example above add reliability: at-least-once to the link Map)
./drain -b localhost -f \
"queue1; {create: receiver, node: {x-declare:{auto-delete:True},
x-bindings: [{exchange: 'amq.topic', queue: 'queue1', key: '*.news'}]}}"
./drain -b localhost -f \
"queue1; {create: receiver, node: {x-declare:{auto-delete:True},
x-bindings: [{exchange: 'amq.topic', queue: 'queue1', key: '*.weather'}]}}"
The following also works for AMQP 0.10
./drain -b localhost -f \
"queue1; {create: receiver, node: {x-declare:{auto-delete:True}}, link:
{x-bindings: [{exchange: 'amq.topic', queue: 'queue1', key: '*.news'}]}}"
./drain -b localhost -f \
"queue1; {create: receiver, node: {x-declare:{auto-delete:True}}, link:
{x-bindings: [{exchange: 'amq.topic', queue: 'queue1', key: '*.weather'}]}}"
Don't know if this is what you are looking for.
Note that in none of the cases above have I worked out how to remove a
binding other than by removing the queue so if you add the first then
the second then delete the second both bindings remain in place - I did
wonder about putting the x-declare/auto delete stuff on the link in the
second AMQP 0.10 example, but that doesn't seem to remove the binding,
so I'm not sure if that's possible.
I need to route the message to the correct application level
destination(s). To do this I need to undertake a matching operation
between the routing key of the message and the binding key(s) of the
created receivers; qpid does not deliver the message to the receiver
with the most exact binding key match.
I guess than I'm not understanding you here. As far as
