-1000 on the Header metadata. 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.
I had already looked at the packets and nothing changed so far. So we are good. But adding information to change semantics on the producer is a non compatible change in my opinion. 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. > > >
