On Thu, Jun 21, 2012 at 3:03 PM, Gordon Sim <[email protected]> wrote: > On 06/21/2012 05:42 PM, Rajith Attapattu wrote: >> >> On Thu, Jun 21, 2012 at 12:16 PM, Gordon Sim <[email protected]> wrote: >>> >>> On 06/21/2012 03:08 PM, Rajith Attapattu wrote: >>>> >>>> >>>> 1. A connection string that contains a URL and an optional list of >>>> properties (for connection options) using the same syntax as address >>>> strings >>>> url ; {k1:v1, k2 :{k1:v1} ...} >>> >>> >>> >>> As I recall, the existing "connection URL" as supported by the JMS client >>> has both 'top level' options that apply whichever broker is in use and >>> 'broker url' options that are in effect only for connections to that >>> specific broker. >> >> >> This is indeed a problem area, all though in practise I don't think >> it's widely used or even useful. >> Could anybody who use this particular feature elaborate a bit more on >> the use cases ? > > > 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. However we could still accommodate this case with the solution I proposed. > >> Some concrete examples of it's usefulness will certainly help us >> understand if we need to accommodate this or not. > > > 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. 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. (2) Provide an alternative to the connection URL format which is quite error prone and ugly. Rajith > > > > > --------------------------------------------------------------------- > 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]
