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>/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") {
reconnectOnLimitExceeded = value;
} else if (name == "container-id" || name == "container_id") {
identifier = value.asString();
} else if (name == "nest-annotations" || name == "nest_annotations") {
nestAnnotations = value;
} else if (name == "set-to-on-send" || name == "set_to_on_send") {
setToOnSend = value;
} else {
throw qpid::messaging::MessagingException(QPID_MSG("Invalid
option: " << name << " not recognised"));
}
}
Note that for qpid::messaging this stuff is all in the connection
options, the actual "URL" is usually just set as just a basic
<host>:<port>, though actually I *think* that it is an AMQP 0.10 URL and
you can actually do amqp:<host>:<port> though TBH I'm not sure if anyone
does.
I do rather wonder that for AMQP 1.0 if the URL could be improved to
accept something like:
amqp://[<user>][:<password>@][<proto>:]<host>[:<port>]
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
personally find that neater, but there might be a good reason for not
doing such a thing.
I mentioned this in my AMQP 1.0 Address Musings "essay", though nobody
has bitten on that one yet :-D
HTH,
Best regards,
Frase
On 07/02/14 15:00, 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. 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
