Rajith,
+1 to this idea - I recently gave up on a simple java based demo because I
couldn't easily figure out the connection syntax (and I was trying to port an
existing python example).
This part esp. blew my mind (From Andrew's mail):
>1) Specifying a "normal" connection URL from the python client:
>url ::= [(amqp|amqps)://][user[/password]@](hostname|literal)[:port]
>
>2) C++ URL including cluster failover list:
>The python client needs to understand this too to participate in
>clustering with failover)
>protocol ::= tcp | ssl | rdma
>address ::= [protocol:](hostname|literal)[:port]
>url::= [amqp:][user[/password]@]address{,address}*
So, even the existing C++ and python clients are inconsistent? Yikes!
We should have One Syntax to Rule Them All, shouldn't we?
For the record, I like Rajith's approach of:
url; {options map}
but I'd move away from putting the failover list into the options map - that's
confusing and probably error prone: can my failover urls have failover urls?
Instead, could our syntax allow a connection to be specified as a list of the
above, and consider the list itself as the failover configuration? Like:
"url1; {options1}, url2; {options2}, ..."
try to connect to url 1 using options1, if fail, try url2... etc.
-K
----- Original Message -----
> On Fri, Jun 22, 2012 at 5:18 AM, Gordon Sim <[email protected]> wrote:
> > 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?
>
> What I meant was that it's rare where you specify different
> properties
> for each broker in the URL list.
> I'm sure there might be valid use cases where that is required, but
> in
> practise I think it's rare.
> Currently neither c++ nor python supports this, but I haven't heard
> any complaints about it either, which makes me think it's not common.
>
> C++ currently supports timeouts, delays, retries etc on a Connection
> level, rather than per url in the reconnect_urls list.
> Perhaps we should do the same (by default) on the Java side for the
> sake of simplicity, but still retaining the ability to do it per url
> if someone really needs it.
> I think it's a reasonable compromise.
>
> > 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).
> They are used uniformly for the majority of the use cases I know
> about, hence my point above about having them as per connection
> properties like C++ and python.
>
> > It also seems reasonable to me to try both ssl and non-ssl
> > connections.
> That I believe could be handled as part of the protocol identifier in
> the URL (i.e tcp vs tls or amqp vs qmqps ..etc)
> >
> > [...]
> >
> >>> 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.
> That is to be expected Sir! ... currently JMS supports per broker-url
> options that neither C++ or python supports.
> So it's impossible to retain backwards compatibility while strictly
> adhering to the C++/python syntax.
>
> What I'm trying to say is that by default the connection-string will
> look and behave exactly the same as c++/python
> But for cases where they really need to have different options for
> each url, then they could use the above format.
>
> Isn't that a reasonable compromise? If not could you pls suggest an
> alternative?
>
> >
> >> 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.
>
> Isn't the current C++ and Python syntax a better alternative ( at
> least for majority of the use cases) ?
> Or are you envisioning something different ?
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
