On Fri, Jun 22, 2012 at 10:47 AM, Ken Giusti <[email protected]> wrote: > 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.
This seems a lot more simple and a lot more readable than the nested approach I suggested. I also agree with the comments made by Rob Godfrey. Rajith > -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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
