You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2008/01/16 22:13:18 UTC
BindingURL format and AMQDestination class
folks,
I see two minor issues with the AMQBindingURL and AMQDestination
The binding URL is defined as follows.
<exch_class>://<exch_name>/[<destination>]/[<queue>]?<option>='<value>'[,<option>='<value>']*
RoutingKey is given as a valid option (See BindingURL class).
Then in AMQDestination we see that the constructors has a field called
"destinationName" (in addition to exchangeName).
As per the AMQP spec, destination refers to the exchange you are publishing.
Therefore the binding url format is incorrect, as destination has no meaning
there.
It cannot be the routing_key as it is given as a valid option. So I propose
we get rid of it.
However the documentation here is correct, but sadly not reflected in the
code properly.
http://cwiki.apache.org/qpid/bindingurlformat.html
Also in AMQDestination, destinationName is used as the routingKey which is
creating confusion and it is also semantically wrong.
The field destinationName should refer to the exchange we are publishing.
But we already have a field named "exchangeName".
So I renamed the field destination to routingKey and modified the code
accordingly in both AMQQueue and AMQTopic.
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: BindingURL format and AMQDestination class
Posted by Arnaud Simon <as...@redhat.com>.
> I think exploring whether the AMQDestination abstraction could be made a
> bit more powerful would be a good thing. E.g. by moving the actions
> performed when creating a subscriber or producer into the AMQDestination
> subclass rather than having that encoded in the session, producer or
> consumer implementations. (I'd need to spend some more time looking at
> the code to be more precise on this).
AMQdestination has been designed for JMS that is to say that nothing
happens at this level.
> That would mean that you could get non-standard behaviour by supplying a
> custom subclass as the destination (however you obtained this
> destination instance). Though using non-standard destinations would
> likely reduce your ability to move between JMS providers, your code
> could process streams of messages using only normal JMS interfaces.
>>From the JMS point of view it may make more sense to extend
MessageConsumer and MessageProducer.
> i.e. I think the AMQDestination could be enhanced to become a single,
> unintrusive extension point that could offer a fair bit of flexibility
> and power.
Whatever class we extend, nothing prevent us to deliver such a ready to
use extension class like for example AMQdestination allowing to add
binding keys.
Re: BindingURL format and AMQDestination class
Posted by Martin Ritchie <ri...@apache.org>.
On 18/01/2008, Gordon Sim <gs...@redhat.com> wrote:
> Martin Ritchie wrote:
> > There should never be a question of using interfaces A or interfaces B
> > that will never work. In Java JMS _IS_ the interfaces used, the only
> > option is to extend it but that should only be for the 1% use cases.
> > Vendor lockin is something AMQP is working to avoid. So in the Java
> > space we should attempt to be pure JMS. The AMQP features can be
> > worked in via config such as JNDI or broker side queue configurations.
>
> I think exploring whether the AMQDestination abstraction could be made a
> bit more powerful would be a good thing. E.g. by moving the actions
> performed when creating a subscriber or producer into the AMQDestination
> subclass rather than having that encoded in the session, producer or
> consumer implementations. (I'd need to spend some more time looking at
> the code to be more precise on this).
>
> That would mean that you could get non-standard behaviour by supplying a
> custom subclass as the destination (however you obtained this
> destination instance). Though using non-standard destinations would
> likely reduce your ability to move between JMS providers, your code
> could process streams of messages using only normal JMS interfaces.
>
> i.e. I think the AMQDestination could be enhanced to become a single,
> unintrusive extension point that could offer a fair bit of flexibility
> and power.
Indeed and in thinking more about the recent changes due to support
the Fanout exchange I realise that I missed the obvious fact that the
BindingURL was reusing the amq.direct queue notion. The fanout
exchange doesn't take a routing key so its value is surely
unimportant. using fanout://amq.fanout//<queue_name> would work just
fine with the current implementation. Ensuring a Destination was
created is all that is required. The JMS Destination abstraction is
the correct point here to correctly abstract the JNDI destinations so
that the code can remain pure JMS. The question of portability then
becomes does vendor a support this destination type. If so adjust
syntax (which AMQP should standardise by the way) and job sorted.
--
Martin Ritchie
Re: BindingURL format and AMQDestination class
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> There should never be a question of using interfaces A or interfaces B
> that will never work. In Java JMS _IS_ the interfaces used, the only
> option is to extend it but that should only be for the 1% use cases.
> Vendor lockin is something AMQP is working to avoid. So in the Java
> space we should attempt to be pure JMS. The AMQP features can be
> worked in via config such as JNDI or broker side queue configurations.
I think exploring whether the AMQDestination abstraction could be made a
bit more powerful would be a good thing. E.g. by moving the actions
performed when creating a subscriber or producer into the AMQDestination
subclass rather than having that encoded in the session, producer or
consumer implementations. (I'd need to spend some more time looking at
the code to be more precise on this).
That would mean that you could get non-standard behaviour by supplying a
custom subclass as the destination (however you obtained this
destination instance). Though using non-standard destinations would
likely reduce your ability to move between JMS providers, your code
could process streams of messages using only normal JMS interfaces.
i.e. I think the AMQDestination could be enhanced to become a single,
unintrusive extension point that could offer a fair bit of flexibility
and power.
Re: BindingURL format and AMQDestination class
Posted by Rajith Attapattu <ra...@gmail.com>.
On Jan 18, 2008 8:48 AM, Gordon Sim <gs...@redhat.com> wrote:
> Arnaud Simon wrote:
> > My point was really that we need to define what an AMQP Destination is
> > and its associated interface and semantics. We'll then provide a way of
> > configuring it from whatever configuration mechanism (It could be JNDI
> > or via provider specific properties). In that way we don't hide non-JMS
> > semantics but document them and keep AMQP JMS implementations
> > inter-operable. The point is really that AMQP should define what a
> > Destination is.
>
> I think I agree with much of this, but for me a destination in AMQP is
> not quite the same thing as a JMS-over-AMQP implementation of the JMS
> Destination interface.
Yes, from what I understand the the concept of destination that I have seen
comming up in discussions is different from a JMS-over-AMQP implementation
of the JMS Destination interface.
>
>
> I believe that (ideally! [1]) the Qpid JMS client should be constructed
> in such a way that you can get a variety of AMQP 'behaviours' [2] based
> on the details of the Destination object you construct your Consumer or
> Producer from. We've got the simple mapping handled reasonably well now,
> but I think we could get more flexibility through some refactoring of
> the code.
Fully agree here.
If we can do that without violating the JMS spec and also using 100% pure
JMS is a big win.
I see a lot of uses cases where you would need to bind a queue to a direct
exchange with a routing key other than the queue name.
Binding a queue with several routing keys or bind your queue to a fanout
exchange.
We should be able to express the power of AMQP through pure JMS as much as
we can.
There are a lot JMS applications out there and if we only provide what they
currently do, then what incentive is there for them to switch?
They wouldn't care whether it is AMQP or not as long as it works.
But if we can provide them with more flexibility, which they can tap without
chaning code then there is a stronger incentive to consider us.
>
> Perhaps in the future the 'official' JMS-over-AMQP mapping will define
> this (or something else) as 'required' flexibility, but in my view we
> should proceed with how we (the Qpid community) believe things should be
> for now.
>
The Qpid community can (and should) influence this mapping.
We can experiment now so we know what works and what doesn't.
> --Gordon
>
> [1] I appreciate its easy to describe my wishes at a high level, and
> rather more effort to actually make them possible. I will try and find
> some time to think things though in more detail.
>
> [2] E.g what exchanges to use, multiple bindings to a queue, whether and
> when things are declared & whether the 'passive' flag is used when so
> doing, whether the 'mandatory' flag is set on published messages,
> whether the exclusive flag is set when issuing a subscribe etc. etc.
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: BindingURL format and AMQDestination class
Posted by Gordon Sim <gs...@redhat.com>.
Arnaud Simon wrote:
> My point was really that we need to define what an AMQP Destination is
> and its associated interface and semantics. We'll then provide a way of
> configuring it from whatever configuration mechanism (It could be JNDI
> or via provider specific properties). In that way we don't hide non-JMS
> semantics but document them and keep AMQP JMS implementations
> inter-operable. The point is really that AMQP should define what a
> Destination is.
I think I agree with much of this, but for me a destination in AMQP is
not quite the same thing as a JMS-over-AMQP implementation of the JMS
Destination interface.
I believe that (ideally! [1]) the Qpid JMS client should be constructed
in such a way that you can get a variety of AMQP 'behaviours' [2] based
on the details of the Destination object you construct your Consumer or
Producer from. We've got the simple mapping handled reasonably well now,
but I think we could get more flexibility through some refactoring of
the code.
Perhaps in the future the 'official' JMS-over-AMQP mapping will define
this (or something else) as 'required' flexibility, but in my view we
should proceed with how we (the Qpid community) believe things should be
for now.
--Gordon
[1] I appreciate its easy to describe my wishes at a high level, and
rather more effort to actually make them possible. I will try and find
some time to think things though in more detail.
[2] E.g what exchanges to use, multiple bindings to a queue, whether and
when things are declared & whether the 'passive' flag is used when so
doing, whether the 'mandatory' flag is set on published messages,
whether the exclusive flag is set when issuing a subscribe etc. etc.
Re: BindingURL format and AMQDestination class
Posted by Arnaud Simon <as...@redhat.com>.
On Fri, 2008-01-18 at 12:12 +0000, Martin Ritchie wrote:
> I disagree it is (or should be) standard JMS-over-AMQP hence you could
> swap for a RabbitMQ or OpenAMQ broker and things work just fine.
>
> What you are doing is creating AMQP Lock-in which is totally different
> to vendor lock-in.
I agree with this statement but only based on this:
> Having a specification document that defines JNDI-BindingURLs,
> ReplyTo and broker side JMS semantics to me is the correct approach to
> take. This leave the vendor free to implement the client and broker as
> they wish but as long as they support the specified JMS functionality
> then you can mix and match JMS Clients and Brokers.
My point was really that we need to define what an AMQP Destination is
and its associated interface and semantics. We'll then provide a way of
configuring it from whatever configuration mechanism (It could be JNDI
or via provider specific properties). In that way we don't hide non-JMS
semantics but document them and keep AMQP JMS implementations
inter-operable. The point is really that AMQP should define what a
Destination is.
Arnaud
Re: BindingURL format and AMQDestination class
Posted by Martin Ritchie <ri...@apache.org>.
On 18/01/2008, Arnaud Simon <as...@redhat.com> wrote:
>
> >
> > Perhaps I misunderstand what you are saying, providing multiple
> > addressing via JNDI will not cause any vendor lock in except in the
> > format and functionality that is specified in the BindingURL (Again
> > this should be an AMQP specified format, which would remove that
> > problem) There would be zero requirement for non pure JMS code in the
> > client library as they would simply do:
> >
> > Destination specialDestination =
> > (Destination)jndiContext.lookup("SpecialAMQPDestination");
> >
> > That is pure JMS + JNDI no AMQP lock-in.
>
> That is pure JMS code with not standard JMS semantics. If your
> application uses this special destination for sending messages to
> several queues you'll then need to re-write it when migrating to another
> JMS provider. What you are doing is introducing a vendor lockin as your
> application will not behave as expected with a "standard" JMS
> implementations. So, what I am saying is that such JMS extensions should
> maybe not be hidden into config files.
I disagree it is (or should be) standard JMS-over-AMQP hence you could
swap for a RabbitMQ or OpenAMQ broker and things work just fine.
What you are doing is creating AMQP Lock-in which is totally different
to vendor lock-in.
Any vendor that implements the JMS-over-AMQP specification can be
used. This is what we are striving for. If we don't hide the binding
configuration and require the use of non standard JMS interfaces we
then require a set of org.amqp.jms interfaces which IMO isn't going to
happen. Having a specification document that defines JNDI-BindingURLs,
ReplyTo and broker side JMS semantics to me is the correct approach to
take. This leave the vendor free to implement the client and broker as
they wish but as long as they support the specified JMS functionality
then you can mix and match JMS Clients and Brokers.
--
Martin Ritchie
Re: BindingURL format and AMQDestination class
Posted by Arnaud Simon <as...@redhat.com>.
>
> Perhaps I misunderstand what you are saying, providing multiple
> addressing via JNDI will not cause any vendor lock in except in the
> format and functionality that is specified in the BindingURL (Again
> this should be an AMQP specified format, which would remove that
> problem) There would be zero requirement for non pure JMS code in the
> client library as they would simply do:
>
> Destination specialDestination =
> (Destination)jndiContext.lookup("SpecialAMQPDestination");
>
> That is pure JMS + JNDI no AMQP lock-in.
That is pure JMS code with not standard JMS semantics. If your
application uses this special destination for sending messages to
several queues you'll then need to re-write it when migrating to another
JMS provider. What you are doing is introducing a vendor lockin as your
application will not behave as expected with a "standard" JMS
implementations. So, what I am saying is that such JMS extensions should
maybe not be hidden into config files.
Re: BindingURL format and AMQDestination class
Posted by Martin Ritchie <ri...@apache.org>.
On 18/01/2008, Arnaud Simon <as...@redhat.com> wrote:
>
>
> > I would have said that a destination with several binding keys is just
> > a short hand notation for requesting multiple deliveries of the
> > message. Compare to SMTP (as AMQP is fond to do) multiple routingkeys
> > on a publish is simply many addresses in the To: field.
>
> That's the only acceptable solution even if I don't like it very much as
> it is equivalent to creating several producers whereas for a consumer
> this is not strictly equivalent to creating several consumers.
>
> > > This being said, we are trying to define those binding URL schemes for
> > > writing pure JMS code that benefits from advanced AMQP features. The
> > > question may therefore be whether we wish to extend the JMS API with
> > > some officially supported new AMQPish features or if we want to ban that
> > > and assume that programmers will either use the JMS or the AMQP API? We
> > > already have extended the JMS API (see org.apache.qpid.jms) so why would
> > > we not do that for adding binding keys to a consumer?
> >
> > There should never be a question of using interfaces A or interfaces B
> > that will never work. In Java JMS _IS_ the interfaces used, the only
> > option is to extend it but that should only be for the 1% use cases.
> > Vendor lockin is something AMQP is working to avoid. So in the Java
> > space we should attempt to be pure JMS. The AMQP features can be
> > worked in via config such as JNDI or broker side queue configurations.
>
> I fully agree with that. However if you use JNDI to define a multiple
> addresses queue instead of using the standard JMS way of crating several
> producers you'll end up with a code that is lock with a specific AMQP
> JMS implementation. Whenever we allow binding destinations that have non
> standard JMS semantics we introduce vendor lockin. This is why I am
> wondering whether this should be explicit or hidden within a config
> file.
Perhaps I misunderstand what you are saying, providing multiple
addressing via JNDI will not cause any vendor lock in except in the
format and functionality that is specified in the BindingURL (Again
this should be an AMQP specified format, which would remove that
problem) There would be zero requirement for non pure JMS code in the
client library as they would simply do:
Destination specialDestination =
(Destination)jndiContext.lookup("SpecialAMQPDestination");
That is pure JMS + JNDI no AMQP lock-in.
Perhaps the thing we are talking around is the fact AMQP haven't yet
standardised the notion of Destination. If we can work out a sensible
solution then that could be proposed, rolled in to the forthcoming
JMS-over-AMQP documentation and vendor lock-in vanishes.
> Arnaud
>
>
>
>
--
Martin Ritchie
Re: BindingURL format and AMQDestination class
Posted by Arnaud Simon <as...@redhat.com>.
> I would have said that a destination with several binding keys is just
> a short hand notation for requesting multiple deliveries of the
> message. Compare to SMTP (as AMQP is fond to do) multiple routingkeys
> on a publish is simply many addresses in the To: field.
That's the only acceptable solution even if I don't like it very much as
it is equivalent to creating several producers whereas for a consumer
this is not strictly equivalent to creating several consumers.
> > This being said, we are trying to define those binding URL schemes for
> > writing pure JMS code that benefits from advanced AMQP features. The
> > question may therefore be whether we wish to extend the JMS API with
> > some officially supported new AMQPish features or if we want to ban that
> > and assume that programmers will either use the JMS or the AMQP API? We
> > already have extended the JMS API (see org.apache.qpid.jms) so why would
> > we not do that for adding binding keys to a consumer?
>
> There should never be a question of using interfaces A or interfaces B
> that will never work. In Java JMS _IS_ the interfaces used, the only
> option is to extend it but that should only be for the 1% use cases.
> Vendor lockin is something AMQP is working to avoid. So in the Java
> space we should attempt to be pure JMS. The AMQP features can be
> worked in via config such as JNDI or broker side queue configurations.
I fully agree with that. However if you use JNDI to define a multiple
addresses queue instead of using the standard JMS way of crating several
producers you'll end up with a code that is lock with a specific AMQP
JMS implementation. Whenever we allow binding destinations that have non
standard JMS semantics we introduce vendor lockin. This is why I am
wondering whether this should be explicit or hidden within a config
file.
Arnaud
Re: BindingURL format and AMQDestination class
Posted by Martin Ritchie <ri...@apache.org>.
On 18/01/2008, Arnaud Simon <as...@redhat.com> wrote:
>
> On Thu, 2008-01-17 at 09:05 +0000, Martin Ritchie wrote:
> > Rajith ,
> >
> > The BindingURL was writing (as it is java) from the JMS point of view.
> > Hence destination is where you are publishing to in JMS. Now the
> > reason the wiki does not match the code is because of a problem I
> > realised after implementing the original spec. The URL cannot have a
> > '#' in the middle as this will prevent the URI class from correctly
> > parsing it. Hence the need to have the routing_key as an option.
> >
> > I would also be very cautious about changing this format as it is used
> > in a lot more places that the Java. I would suggest that if you do
> > wish to change the format then changing the code so that it matches
> > the wiki documentation would be the way to go. If you do that then a
> > change will be needed to update the C++ and .NET as they both use this
> > format to encode the replyTo field.
>
> I think that AMQP should define the replyTo URL. If this is not already
> the case we should then raise this issue with the AMQP list.
>From what I've been told it does in 0-10
> > Really what should happen is that the BindingURL be used solely on the
> > broker for parsing the bindings defined in the configuration file and
> > either a simplified version or a new format be decided for replyTo
> > encoding. We used to use Q|T+RoutingKey but that limited us in the
> > java to only using the built in exchanges. Perhaps a subclass of
> > BindingURL could be used to only present the values required to
> > perform a reply.
>
> To be honest we had troubles with the binding URL when trying to get the
> JMS code inter-operate with c++ and python samples. For doing that we
> needed to use the faneout exchange, to use a different binding key than
> the queue name and to bind a queue with more than one binding key.
Then that is mainly a failing of client.AMQQueue not the BindingURL.
It would already return the routingKey if the exchange was amq.direct,
which in the fanout case it isn't
> This reminds me some discussion we recently had on the AMQP list about
> how to decide whether a JMS topic exists and a way of solving that issue
> would be to define AMQP alias for an exchange, routing-key(s) pair. It
> could be a good idea to start thinking about this wider notion of AMQ
> destination. However the issue is that AMQP destinations are not
> matching the notion of JMS one. If we consider the current binding URL
> scheme and what people want to achieve, a destination would be defined
> by: an exchange name, an optional queue name, some optional binding keys
> and options. This has however different semantics whether we use the
> destination for consuming or for producing. What does that means
> producing a message to a destination with several binding keys? That's
> hard to say and I would say that it makes no sense. This is why I would
> suggest that we do not allow using more than one binding key unless we
> introduce a kind of "read only" notion. A "read only" destination would
> only be used for consumption.
I would have said that a destination with several binding keys is just
a short hand notation for requesting multiple deliveries of the
message. Compare to SMTP (as AMQP is fond to do) multiple routingkeys
on a publish is simply many addresses in the To: field.
> This being said, we are trying to define those binding URL schemes for
> writing pure JMS code that benefits from advanced AMQP features. The
> question may therefore be whether we wish to extend the JMS API with
> some officially supported new AMQPish features or if we want to ban that
> and assume that programmers will either use the JMS or the AMQP API? We
> already have extended the JMS API (see org.apache.qpid.jms) so why would
> we not do that for adding binding keys to a consumer?
There should never be a question of using interfaces A or interfaces B
that will never work. In Java JMS _IS_ the interfaces used, the only
option is to extend it but that should only be for the 1% use cases.
Vendor lockin is something AMQP is working to avoid. So in the Java
space we should attempt to be pure JMS. The AMQP features can be
worked in via config such as JNDI or broker side queue configurations.
> Arnaud
--
Martin Ritchie
Re: BindingURL format and AMQDestination class
Posted by Arnaud Simon <as...@redhat.com>.
On Thu, 2008-01-17 at 09:05 +0000, Martin Ritchie wrote:
> Rajith ,
>
> The BindingURL was writing (as it is java) from the JMS point of view.
> Hence destination is where you are publishing to in JMS. Now the
> reason the wiki does not match the code is because of a problem I
> realised after implementing the original spec. The URL cannot have a
> '#' in the middle as this will prevent the URI class from correctly
> parsing it. Hence the need to have the routing_key as an option.
>
> I would also be very cautious about changing this format as it is used
> in a lot more places that the Java. I would suggest that if you do
> wish to change the format then changing the code so that it matches
> the wiki documentation would be the way to go. If you do that then a
> change will be needed to update the C++ and .NET as they both use this
> format to encode the replyTo field.
I think that AMQP should define the replyTo URL. If this is not already
the case we should then raise this issue with the AMQP list.
> Really what should happen is that the BindingURL be used solely on the
> broker for parsing the bindings defined in the configuration file and
> either a simplified version or a new format be decided for replyTo
> encoding. We used to use Q|T+RoutingKey but that limited us in the
> java to only using the built in exchanges. Perhaps a subclass of
> BindingURL could be used to only present the values required to
> perform a reply.
To be honest we had troubles with the binding URL when trying to get the
JMS code inter-operate with c++ and python samples. For doing that we
needed to use the faneout exchange, to use a different binding key than
the queue name and to bind a queue with more than one binding key.
This reminds me some discussion we recently had on the AMQP list about
how to decide whether a JMS topic exists and a way of solving that issue
would be to define AMQP alias for an exchange, routing-key(s) pair. It
could be a good idea to start thinking about this wider notion of AMQ
destination. However the issue is that AMQP destinations are not
matching the notion of JMS one. If we consider the current binding URL
scheme and what people want to achieve, a destination would be defined
by: an exchange name, an optional queue name, some optional binding keys
and options. This has however different semantics whether we use the
destination for consuming or for producing. What does that means
producing a message to a destination with several binding keys? That's
hard to say and I would say that it makes no sense. This is why I would
suggest that we do not allow using more than one binding key unless we
introduce a kind of "read only" notion. A "read only" destination would
only be used for consumption.
This being said, we are trying to define those binding URL schemes for
writing pure JMS code that benefits from advanced AMQP features. The
question may therefore be whether we wish to extend the JMS API with
some officially supported new AMQPish features or if we want to ban that
and assume that programmers will either use the JMS or the AMQP API? We
already have extended the JMS API (see org.apache.qpid.jms) so why would
we not do that for adding binding keys to a consumer?
Arnaud
Re: BindingURL format and AMQDestination class
Posted by Martin Ritchie <ri...@apache.org>.
On 17/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> After the discussions with Martin and Robert here is what I think.
> The BindingURL was used for 3 things in the code.
> 1) The broker used it (apparently not anymore - which is good)
> 2) ReplyTo - still the 0-8 clients use this and needs to support it.
> 3) JNDI
>
> I propose we revamp the BindingURL to support the following use cases. So we
> can have some flexibility while still using 100% pure JMS.
>
> 1) First and foremost we need to maintain backward compatibility to maintain
> the 0-8 stuff.
>
> 2) Allow an AMQQueue to use a routing key different from the queue name.
>
> 3) Allow an AMQQueue to bind to a Fannout exchange.
>
> 4) Allow to bind to a queue with more than one routing key.
>
> The change I made have broken use case 1 slightly. I need to fix that.
> Option 2 and 3 can be done with the current changes.
> Option 4 needs to be thought through as it has some implications on a
> producer etc.
>
> One suggestion is to have a list of rotingkeys.
> Ex. direct://amq.direct/queueName?routingKey="rk1 del rk2 del rk3 .."
> We need to find a suitable delimiter for this.
> For the issue with producers, when we define a destination for the producer
> we can put only one. Or if a list is there we can take the first one.
My suggestion to maintain compatibility with existing JNDI clients
would be to have multiple routkingKey options taking your example:
direct://amq.direct/queueName?routingKey="rk1"&routingKey="rk2&routingKey="rk3"
This would allow the M2 JNDI parser to work it would end up with
routingKey = rk3 but then the new parser would beable to know that
there were multiple queues associated with it so it could send
multiple bind requests or send multiple messages to each routingkey.
On a related note I'm still not sure that the java client should
automatically create queues beyond the simplistic queueName ==
routingKey, if it should even do that. Other JMS providers require
that the queues be already created by and admin on the broker. This
approach would certainly get around the client having to do any
multiple routingKey configuration.
If we start down the road to multiple routingKeys in JNDI then it just
begs the question of how I do this:
My application consumes a number of sources of data I'm lazy and just
want one subscription. AMQP allows me to do this so I'd like to have
my ConsumeQueue bound as follows: To Topics uk.wholesaleprices.# &
us.wholesaleprices.# , Direct rk Orders.
The current URL only supports binding to a single exchange so the
above would have to be done with at least two JNDI queues. Perhaps the
solution is to have a new format that would solve any legacy JNDI
support and allow for future compatibility. A sequence of 0-10 ReplyTo
Formatted values perhaps.
Just my thoughts
Martin
> Comments are critisisms are equally welcomed.
>
> Rajith
>
> On Jan 17, 2008 4:05 AM, Martin Ritchie <ri...@apache.org> wrote:
>
> > Rajith ,
> >
> > The BindingURL was writing (as it is java) from the JMS point of view.
> > Hence destination is where you are publishing to in JMS. Now the
> > reason the wiki does not match the code is because of a problem I
> > realised after implementing the original spec. The URL cannot have a
> > '#' in the middle as this will prevent the URI class from correctly
> > parsing it. Hence the need to have the routing_key as an option.
> >
> > I would also be very cautious about changing this format as it is used
> > in a lot more places that the Java. I would suggest that if you do
> > wish to change the format then changing the code so that it matches
> > the wiki documentation would be the way to go. If you do that then a
> > change will be needed to update the C++ and .NET as they both use this
> > format to encode the replyTo field.
> >
> > Really what should happen is that the BindingURL be used solely on the
> > broker for parsing the bindings defined in the configuration file and
> > either a simplified version or a new format be decided for replyTo
> > encoding. We used to use Q|T+RoutingKey but that limited us in the
> > java to only using the built in exchanges. Perhaps a subclass of
> > BindingURL could be used to only present the values required to
> > perform a reply.
> >
> >
> > On 16/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> > > folks,
> > >
> > > I see two minor issues with the AMQBindingURL and AMQDestination
> > > The binding URL is defined as follows.
> > >
> > <exch_class>://<exch_name>/[<destination>]/[<queue>]?<option>='<value>'[,<option>='<value>']*
> > > RoutingKey is given as a valid option (See BindingURL class).
> > >
> > > Then in AMQDestination we see that the constructors has a field called
> > > "destinationName" (in addition to exchangeName).
> > >
> > > As per the AMQP spec, destination refers to the exchange you are
> > publishing.
> > > Therefore the binding url format is incorrect, as destination has no
> > meaning
> > > there.
> > > It cannot be the routing_key as it is given as a valid option. So I
> > propose
> > > we get rid of it.
> > > However the documentation here is correct, but sadly not reflected in
> > the
> > > code properly.
> > > http://cwiki.apache.org/qpid/bindingurlformat.html
> > >
> > > Also in AMQDestination, destinationName is used as the routingKey which
> > is
> > > creating confusion and it is also semantically wrong.
> > > The field destinationName should refer to the exchange we are
> > publishing.
> > > But we already have a field named "exchangeName".
> > > So I renamed the field destination to routingKey and modified the code
> > > accordingly in both AMQQueue and AMQTopic.
> > >
> > > --
> > > Regards,
> > >
> > > Rajith Attapattu
> > > Red Hat
> > > blog: http://rajith.2rlabs.com/
> > >
> >
> >
> > --
> > Martin Ritchie
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>
--
Martin Ritchie
Re: BindingURL format and AMQDestination class
Posted by Rajith Attapattu <ra...@gmail.com>.
After the discussions with Martin and Robert here is what I think.
The BindingURL was used for 3 things in the code.
1) The broker used it (apparently not anymore - which is good)
2) ReplyTo - still the 0-8 clients use this and needs to support it.
3) JNDI
I propose we revamp the BindingURL to support the following use cases. So we
can have some flexibility while still using 100% pure JMS.
1) First and foremost we need to maintain backward compatibility to maintain
the 0-8 stuff.
2) Allow an AMQQueue to use a routing key different from the queue name.
3) Allow an AMQQueue to bind to a Fannout exchange.
4) Allow to bind to a queue with more than one routing key.
The change I made have broken use case 1 slightly. I need to fix that.
Option 2 and 3 can be done with the current changes.
Option 4 needs to be thought through as it has some implications on a
producer etc.
One suggestion is to have a list of rotingkeys.
Ex. direct://amq.direct/queueName?routingKey="rk1 del rk2 del rk3 .."
We need to find a suitable delimiter for this.
For the issue with producers, when we define a destination for the producer
we can put only one. Or if a list is there we can take the first one.
Comments are critisisms are equally welcomed.
Rajith
On Jan 17, 2008 4:05 AM, Martin Ritchie <ri...@apache.org> wrote:
> Rajith ,
>
> The BindingURL was writing (as it is java) from the JMS point of view.
> Hence destination is where you are publishing to in JMS. Now the
> reason the wiki does not match the code is because of a problem I
> realised after implementing the original spec. The URL cannot have a
> '#' in the middle as this will prevent the URI class from correctly
> parsing it. Hence the need to have the routing_key as an option.
>
> I would also be very cautious about changing this format as it is used
> in a lot more places that the Java. I would suggest that if you do
> wish to change the format then changing the code so that it matches
> the wiki documentation would be the way to go. If you do that then a
> change will be needed to update the C++ and .NET as they both use this
> format to encode the replyTo field.
>
> Really what should happen is that the BindingURL be used solely on the
> broker for parsing the bindings defined in the configuration file and
> either a simplified version or a new format be decided for replyTo
> encoding. We used to use Q|T+RoutingKey but that limited us in the
> java to only using the built in exchanges. Perhaps a subclass of
> BindingURL could be used to only present the values required to
> perform a reply.
>
>
> On 16/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> > folks,
> >
> > I see two minor issues with the AMQBindingURL and AMQDestination
> > The binding URL is defined as follows.
> >
> <exch_class>://<exch_name>/[<destination>]/[<queue>]?<option>='<value>'[,<option>='<value>']*
> > RoutingKey is given as a valid option (See BindingURL class).
> >
> > Then in AMQDestination we see that the constructors has a field called
> > "destinationName" (in addition to exchangeName).
> >
> > As per the AMQP spec, destination refers to the exchange you are
> publishing.
> > Therefore the binding url format is incorrect, as destination has no
> meaning
> > there.
> > It cannot be the routing_key as it is given as a valid option. So I
> propose
> > we get rid of it.
> > However the documentation here is correct, but sadly not reflected in
> the
> > code properly.
> > http://cwiki.apache.org/qpid/bindingurlformat.html
> >
> > Also in AMQDestination, destinationName is used as the routingKey which
> is
> > creating confusion and it is also semantically wrong.
> > The field destinationName should refer to the exchange we are
> publishing.
> > But we already have a field named "exchangeName".
> > So I renamed the field destination to routingKey and modified the code
> > accordingly in both AMQQueue and AMQTopic.
> >
> > --
> > Regards,
> >
> > Rajith Attapattu
> > Red Hat
> > blog: http://rajith.2rlabs.com/
> >
>
>
> --
> Martin Ritchie
>
--
Regards,
Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/
Re: BindingURL format and AMQDestination class
Posted by Martin Ritchie <ri...@apache.org>.
Rajith ,
The BindingURL was writing (as it is java) from the JMS point of view.
Hence destination is where you are publishing to in JMS. Now the
reason the wiki does not match the code is because of a problem I
realised after implementing the original spec. The URL cannot have a
'#' in the middle as this will prevent the URI class from correctly
parsing it. Hence the need to have the routing_key as an option.
I would also be very cautious about changing this format as it is used
in a lot more places that the Java. I would suggest that if you do
wish to change the format then changing the code so that it matches
the wiki documentation would be the way to go. If you do that then a
change will be needed to update the C++ and .NET as they both use this
format to encode the replyTo field.
Really what should happen is that the BindingURL be used solely on the
broker for parsing the bindings defined in the configuration file and
either a simplified version or a new format be decided for replyTo
encoding. We used to use Q|T+RoutingKey but that limited us in the
java to only using the built in exchanges. Perhaps a subclass of
BindingURL could be used to only present the values required to
perform a reply.
On 16/01/2008, Rajith Attapattu <ra...@gmail.com> wrote:
> folks,
>
> I see two minor issues with the AMQBindingURL and AMQDestination
> The binding URL is defined as follows.
> <exch_class>://<exch_name>/[<destination>]/[<queue>]?<option>='<value>'[,<option>='<value>']*
> RoutingKey is given as a valid option (See BindingURL class).
>
> Then in AMQDestination we see that the constructors has a field called
> "destinationName" (in addition to exchangeName).
>
> As per the AMQP spec, destination refers to the exchange you are publishing.
> Therefore the binding url format is incorrect, as destination has no meaning
> there.
> It cannot be the routing_key as it is given as a valid option. So I propose
> we get rid of it.
> However the documentation here is correct, but sadly not reflected in the
> code properly.
> http://cwiki.apache.org/qpid/bindingurlformat.html
>
> Also in AMQDestination, destinationName is used as the routingKey which is
> creating confusion and it is also semantically wrong.
> The field destinationName should refer to the exchange we are publishing.
> But we already have a field named "exchangeName".
> So I renamed the field destination to routingKey and modified the code
> accordingly in both AMQQueue and AMQTopic.
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> blog: http://rajith.2rlabs.com/
>
--
Martin Ritchie