Re: In our scenario we want something that independently forwards messages between queues in different brokers...Here's an illustration...
To me it looks like your illustration is depicting a scenario where messages are exchanged between Alice and Bob. That's exactly the kind of functionality that the router provides, and it can do so without requiring a broker. I'm guessing that there's something else in your use-case that requires a broker otherwise you would already be using the router. Unfortunately that particular details remains obscured. Re: are there any rough perf metrics for Core vs JMS bridges? I'm not aware of any metrics. What's your throughput and latency goals? Have you performed any benchmarks to know that a JMS bridge doesn't meet your goal(s)? Re: ...I was wondering how difficult it would be to build a custom Core -> AMQP bridge... Why would you need to build a custom bridge? Camel, as I have already suggested, has a bridge that you could use. Re: Are there any backwards-compatibility guarantees for the Core protocol? There's always the potential for bugs, but backwards compatibility is a priority. Justin On Wed, Aug 2, 2017 at 11:38 AM, adagys <andrius.da...@r3.com> wrote: > So I had a look at qpid-dispatch, but it doesn't seem to solve our problem. > Unless I'm misunderstanding, the way it works is that a client > (consumer/producer) connects to the router, which then links it to another > endpoint – a queue inside a broker, or producer/consumer. In our scenario > we > want something that independently forwards messages between queues in > different brokers. > > Here's an illustration: > > <http://activemq.2283324.n4.nabble.com/file/n4729171/Corda_Messaging.png> > > A client connects to the broker, posts a message to the "outgoing" queue > and > waits for a response on the "incoming" queue. The message then gets > forwarded to an "incoming" queue on another broker, where it gets processed > by the recipient. A response is sent back the same way. The blue lines > currently represent Core bridges. > > What we want to achieve is have a bridging mechanism that works over AMQP, > so e.g. Broker 1 could be Artemis and Broker 2, say, Qpid. It may well be > that JMS bridges is the best solution here, but the docs mention that it's > less performant (are there any rough perf metrics for Core vs JMS > bridges?), > so I was wondering how difficult it would be to build a custom Core -> AMQP > bridge (even if it only works one way in this case). > > Our second concern is backwards-compatibility, and having all communication > done via AMQP solves that. Are there any backwards-compatibility guarantees > for the Core protocol? > > Thanks again for your help! > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/Artemis-AMQP-bridges-tp4728934p4729171.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
