On 25/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
On Wed, 2007-07-25 at 16:34 +0100, Martin Ritchie wrote:
> On 25/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-07-25 at 10:16 +0100, Martin Ritchie wrote:
> > > I'm not exactly sure what advantage this would give us over the
> > > current ConnectionURL syntax.
> >
> > The aim was to simplify the current approach.
>
> Just so we are all clear this is the current approach
>
url=amqp://[<user>:<pass>@][<clientid>]/<virtualhost>?brokerlist='<brokerdetail>[;[<brokerdetail>]'
>
>
brokerdetail=<protocol>://<host>[:<port>][[?<option>='<value>'],[<option>='<value>']*]
>
The point I am making is that using properties would simplify the most
common URLs. Moreover, we cannot think about everything so if we want to
add staff I think that is easier and more natural to add additional
properties rather than extending the URL.
Is adding option=value to the end of a url really more complex than
putting it on a new line?
I would say that you would require more information in the new line
approach so that you can associate that option to the specific
connnectionfactory defined in the file.
> > > I don't see how you would convert the following URL in the current
> > > format to the what you suggest above:
> > >
> > > connectionfactory.local =
> > > amqp://guest:[EMAIL
PROTECTED]/test?brokerlist='vm://:1;tcp://localhost:5672;sctp://host:port'
> >
> > It would be:
> > connectionfactory=amqp://localhost:5672/test
> > amqp.clientId=clientid
> > amqp.brokerURL.2=amqp://host:port/test
> > amqp.transportType.2=sctp
> > amqp.encryption.2=ssl
>
> But this has no vm://:1 nor any relationship between items. what if I had
>
> connectionfactory2=amqp://specialhost:4564/private
>
> Would the two clients using this connection factory use the same
amqp.clientId?
> How would failover work, would both connectionfactories use
> brokerURL.2 as a failover host?
Maybe I don't have the same view than you regarding failover. To me you
would failover between nodes of a cluster i.e. the brokers are
conceptually identical. This means that for the client point of view
this does not matter which node it is talking to. Hence, I would have a
single connection factory that creates a Qpid connection that knows how
to failover between the cluster nodes. Are you seeing failover
differently?
I don't think I'm seeing failover differently but I think we are
seeing the JNDI properties file differently. I see one file with a
number of connectionfactories defined that can be used to connect to a
number of different clusters. Hence that connection factory needs to
know all the broker details associated with that connection/cluster.
From what you are saying would I be correct in thinking that you see
the JNDI properties file with at most a single cluster defined.
> Again for clarity here is our current BindingURL
>
<exch_class>://<exch_name>/[<destination>]/[<queue>][[?<option>='<value>'][,<option>='<value>']*]
>
>
> > > What would the benefit of performing the broker destination lookup
> > > when performing the JNDI Conext lookup? What connection details would
> > > use to connect to the broker and perform that lookup? Are you
> > > suggesting that destinations are associated with a broker?
> >
> > I was not suggesting that. I was saying that we should provide a
> > destination management AP instead of including everything in the URL.
>
> I'm not sure if I follow how this would work. Our current setup allows
> for the JMS Destination that is being used by a client to be altered
> with zero code changes. This Is this something that a destination
> management API would also need to allow.
I get your point now. I had in mind that in the JMS world you would have
to use a management tool to create the destination on your broker. I
don't really like the approach of creating the destination when a
consumer is created. I would prefer to keep your approach but to create
the destinations when the connection factory is created. I would
moreover provide a simple management tool for people that are JMS
nostalgic (this would also help providing simple samples).
Arnaud
I agree that having a tool to create queues/topics/destinations on the
broker would be helpful as that is what people expect when migrating
from other messaging products. The current automatic declaration is a
convenience for JMS users.
However that said looking up a JNDI object doesn't cause any creation
on the broker. I did h ave a patch to commit to add a System Property
which would stop the client performing exchange/queue declare for each
new consumer. So if the queues didn't exist they would get an error.
It appears I forgot to commit it :) (more likely hadn't fully tested
it)
When we have full ACLs on the broker then would have no need for this
as the client would have to have permission to declare
queues/exchanges. So some sort of tool will be required at that stage.
--
Martin Ritchie
