Clebert, This can work. If you look at the ARTEMIS-780 branch and see how we've approached this, you'll notice that we don't touch any of the internal APIs. It's only a few methods added. Having two addresses in the config, is not really creating two addressing inside of Artemis. There's only one address and all queues have this address. The only thing that changes is the fact that a queue binding now has some meta-data (an AddressInfo object) that determines how messages are routed to it. It's perfectly viable to have 2 queues, with the same address, but with different address info objects.
As for the producer case, we could just add a message header that identifies that this was sent for addresses with "multicast" only. And put the appropriate filter on the queues when they're created. In summary, it's possible, the question is whether this is the correct approach. I'm open to ideas, but I don't think anyone has suggested anything as of yet that covers all use cases. Cheers Martyn On Thu, Nov 17, 2016 at 12:28 PM, Clebert Suconic <[email protected] > wrote: > > 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. >
