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]
