On Fri, Nov 18, 2016 at 1:16 PM, Clebert Suconic <[email protected]> wrote:
> -1000 on the Header metadata. What header meta-data are you talking about? > > This is the same as changing the wire. It > won't be possible to provide compatibility with older Artemis 1.0,1,2,3,4 > and 1.5 clients. Beyond Hornetq compatibility. > In what way? please be specific. > > I had already looked at the packets and nothing changed so far. There is no need to change any packet in what I've suggested. > So we are > good. But adding information to change semantics on the producer is a non > compatible change in my opinion. What do you mean on the producer? That's not what I am suggesting. > On Fri, Nov 18, 2016 at 6:44 AM Martyn Taylor <[email protected]> wrote: > > > 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. > > > > > >
