Any update on this, Erik?
Justin On Fri, Jun 13, 2025 at 10:53 AM Devriendt, Erik <erik.devrie...@siemens.com.invalid> wrote: > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > >
