That might be acceptable, depending on the time needed to detect the
disconnection and perform the failover.
I will do some tests next week.
-----Original Message-----
From: Justin Bertram <jbert...@apache.org>
Sent: Friday, 13 June 2025 16:26
To: users@activemq.apache.org
Subject: Re: How to set Artemis property _AMQ_DUPL_ID in a MQTT client?
> No, the producer sends messages to a queue "cms.test.c.client.queue",
> the consumer reads from that queue.
To be clear, I don't believe these two use-cases are directly comparable due to
the difference between pub/sub & point-to-point semantics, but I digress.
Regarding your federation configuration...If you're only looking for redundancy
would it not be sufficient to specify 2 connectors for a single upstream config
instead of 2 upstream configs each with 1 connector? For
example:
<federations>
<federation name="ebp-ede-federation">
<upstream name="edeop2-upstream">
<circuit-breaker-timeout>1000</circuit-breaker-timeout>
<static-connectors>
<connector-ref>edeop2-connector-1</connector-ref>
<connector-ref>edeop2-connector-2</connector-ref>
</static-connectors>
<policy ref="policySetA"/>
</upstream>
<policy-set name="policySetA">
<policy ref="address-federation" />
</policy-set>
<address-policy name="address-federation" >
<include address-match="cms.#" />
</address-policy>
</federation>
</federations>
This would eliminate the duplication problem with pub/sub use-cases (e.g.
MQTT) and simplify your configuration.
Justin
On Thu, Jun 12, 2025 at 7:25 AM Devriendt, Erik
<erik.devrie...@siemens.com.invalid> wrote:
> > I think I see now, but I want to confirm since I've not seen this
> > kind
> of configuration before. You've intentionally configured 2 federation
> connections in a redundant fashion so that each connection is sending
> the same message resulting in duplicates on the target. Is that correct?
> Yes. That is correct.
>
> > Are you using pub/sub in your OpenWire use-case?
> No, the producer sends messages to a queue "cms.test.c.client.queue",
> the consumer reads from that queue.
>
> > Also, can you share your federation config from broker.xml?
> Sure. Here it is:
>
> On Machine A (edeop2)
> -------------------
> ...
> <name>edeop2</name>
> ...
> <connectors>
> <connector name="artemis-connector">tcp://0.0.0.0:61616
> </connector>
> <connector
> name="ebp-ede-connector-1">tcp://192.168.101.203:61616
> </connector>
> <connector
> name="ebp-ede-connector-2">tcp://192.168.102.203:61616
> </connector>
> <connector
> name="edeop2-connector-1">tcp://192.168.101.204:61616
> </connector>
> <connector
> name="edeop2-connector-2">tcp://192.168.102.204:61616
> </connector>
> </connectors>
> ...
> <federations>
> <federation name="ebpop2-federation">
> <upstream name="ebp-ede-upstream-1">
> <circuit-breaker-timeout>1000</circuit-breaker-timeout>
> <static-connectors>
> <connector-ref>ebp-ede-connector-1</connector-ref>
> </static-connectors>
> <policy ref="policySetA"/>
> </upstream>
> <upstream name="ebp-ede-upstream-2">
> <circuit-breaker-timeout>1000</circuit-breaker-timeout>
> <static-connectors>
> <connector-ref>ebp-ede-connector-2</connector-ref>
> </static-connectors>
> <policy ref="policySetA"/>
> </upstream>
> <policy-set name="policySetA">
> <policy ref="address-federation" />
> </policy-set>
> <address-policy name="address-federation">
> <include address-match="cms.#" />
> </address-policy>
> </federation>
> </federations>
>
>
> On machine B (ebp-ede)
> ------------------
> ...
> <name>ebp-ede</name>
> ...
> <connectors>
> <connector name="artemis-connector">tcp://0.0.0.0:61616
> </connector>
> <connector
> name="ebp-ede-connector-1">tcp://192.168.101.203:61616
> </connector>
> <connector
> name="ebp-ede-connector-2">tcp://192.168.102.203:61616
> </connector>
> <connector
> name="edeop2-connector-1">tcp://192.168.101.204:61616
> </connector>
> <connector
> name="edeop2-connector-2">tcp://192.168.102.204:61616
> </connector>
> </connectors>
> ...
> <federations>
> <federation name="ebp-ede-federation">
> <upstream name="edeop2-upstream-1">
> <circuit-breaker-timeout>1000</circuit-breaker-timeout>
> <static-connectors>
> <connector-ref>edeop2-connector-1</connector-ref>
> </static-connectors>
> <policy ref="policySetA"/>
> </upstream>
> <upstream name="edeop2-upstream-2">
> <circuit-breaker-timeout>1000</circuit-breaker-timeout>
> <static-connectors>
> <connector-ref>edeop2-connector-2</connector-ref>
> </static-connectors>
> <policy ref="policySetA"/>
> </upstream>
> <policy-set name="policySetA">
> <policy ref="address-federation" />
> </policy-set>
> <address-policy name="address-federation" >
> <include address-match="cms.#" />
> </address-policy>
> </federation>
> </federations>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
> For additional commands, e-mail: users-h...@activemq.apache.org For
> further information, visit:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Facti
> vemq.apache.org%2Fcontact&data=05%7C02%7Cerik.devriendt%40siemens.com%
> 7C3d647a9d186947a8347708ddaa866bba%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%7C0%7C638854216478521907%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> 3D%3D%7C0%7C%7C%7C&sdata=4zId8xnVWHSEB2qImGqfbeyv70yfHcoU4dHrdLF1za0%3
> D&reserved=0
>
>
