activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0
Date Thu, 17 Nov 2016 12:28:16 GMT
> Just so I understand exactly what you are saying here.  You're saying that
> a client sends to "foo" and a consumer received messages sent to "foo".  In
> order for the consumer to consume from "foo" it passes in either "foo",
> "queue:///foo" or "topic:///foo" which determines how the messages are
> propagated to the client?  "foo" means let the broker decide,
> "queue:///foo" and "topic:///foo" mean let the client decide.  In addition
> to these two approaches, it may be that the protocol itself wants to
> decide.  MQTT for example, always requires a subscription.
>
> One way to do this, not straying too far from the original proposal, would
> be to make the address uniqueness a combination of the routing type and the
> address name.  This would allow something like:
>
> <address name="foo" routingType="anycast">
> <address name="foo" routingType="multicast">
>
> We'd need to ensure there is a precedent set for times when a subscriber
> just subscribes to "foo".  I'd say it makes sense for "multicast" to take
> precedence in this case.


That wouldn't work. You would need to change the API to pass in an
address type, the protocols to have an address type (in a way it
wouldn't be compatible with previous clients).

I think this is settled if you make the prefix configurable for cases
where users want to have such thing.

Mime
View raw message