On 06/22/2012 01:38 AM, Rajith Attapattu wrote:
On Thu, Jun 21, 2012 at 3:03 PM, Gordon Sim <[email protected]> wrote:I think its intended for cases where the set of brokers to connect to are not part of a homogeneous cluster. So with the current 'broker url' options, it may for example in some cases be desired to have different retry and timeout options (to favour certain brokers over others perhaps), or have ssl on for some brokers in the list and off for others.This is the one use case I also thought of, but I believe it's rarely used.
Depends what you mean by rarely used. The *only* way of controlling the retries, timeouts and delays when attempting to connect to brokers in the list is through broker url options, right?
Is your point that you think they are always used uniformly or that these options aren't used at all? (I know at least one case where the options are used).
It also seems reasonable to me to try both ssl and non-ssl connections. [...]
I guess the question is whether you are simply proposing a new syntax for expressing the existing options or potentially proposing a new set of options.A new syntax for expressing the existing options. This syntax is more or less the same as the one C++ client is using. And I believe we can accommodate the use case you mentioned above with the solution I proposed.
You mean:
url; {k1:v1, reconnect_urls : { url; {options}, url; {options...}... }... }
? I don't like that. It would no longer match the python or c++ syntax.
My goals are to, (1) Bring the Java/JMS client inline with the other clients. We have increasingly encountered cases where the applications that are used in a Qpid deployment are written in a multitude of languages. A common URL format will make things easy, just like the common addressing syntax.
Only if it *is* the same and if the set of options are the same (or at least close). Making things look similar on the surface when they are in fact completely different under the covers is not always an improvement.
(2) Provide an alternative to the connection URL format which is quite error prone and ugly.
I agree that the connection "URL" format is rather awkward and would welcome a more intuitive alternative.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
