You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Timothy Bish <ta...@gmail.com> on 2024/07/01 18:42:29 UTC
Re: Need help with federation setup with ActiveMq
On 6/26/24 06:56, Saju Daniel wrote:
> Hello,
>
> Just a gentle reminder. The issue is kind of critical for us to
> implement federation on our setup .
> Please let me know if you need more information on the problem.
>
After talking to Justin Bertram about some core client details I tried
your setup and it appears that setting the Core client ackBatchSize
value to something smaller than the default causes your test to work as
expected.
The connector can be configured using URI like:
<connector
name="europe-01-connector">tcp://0.0.0.0:61616?ackBatchSize=100</connector>
Your testing is not filling the default window and so the client has not
sent the acknowledgements.
> Regards,
> Saju
>
>
> On Tue, 25 Jun 2024 at 16:50, Saju Daniel <ds...@gmail.com> wrote:
>
> Hello Tim ,
>
> The issue seems to be easy to reproduce. Nevertheless I am adding
> the steps and configuration I used for my tests .
> It would be great if you could kindly review the configuration.
> These steps can be also used to create a bug report if needed .
>
> 1. Install activeMq 2.35 and create 2 single node brokers
> representing the EU(broker1) and USA(broker2) cluster.
>
> .\artemis create ../broker2;.\artemis create ../broker2
>
> 2. Modify the broker.xml to add the federation configuration on
> both the brokers. Attached the broker.xml files on each setup.
> Since I am running the setup on same host I have adjusted the port
> to avoid conflict
>
> 3. Start both the brokers.
>
> 4. Start the consumer on broker2
>
> .\artemis.cmd consumer --destination
> events.#::audit-trail-shared.multicast --url tcp://0.0.0.0:61617
> <http://0.0.0.0:61617>
>
> 5. Create the producer on broker1
>
> .\artemis.cmd queue create --url tcp://0.0.0.0:61616
> <http://0.0.0.0:61616> --address events.name.v1.seminars --name
> test --multicast --durable Y --purge-on-no-consumers N
> --auto-create-address Y
>
> 6. Check the queue status on broker1. The federated queue is
> created on the broker1
>
> .\artemis.cmd queue stat --field ADDRESS --value
> 'events.name.v1.seminars' --operation EQUALS --url
> tcp://localhost:61616
> image.png
>
> 7. Create a jms_client to send messages using multicast route .
> (jms_client.zip) attached .
>
> 8. Compile and execute the program to send multicast message on
> the address events.name.v1.seminars
>
> mvn compile exec:java
> mvn exec:java
>
> 9. Check the message queue on broker1 and broker2
>
> *broker1*
> .\artemis.cmd queue stat --field ADDRESS --value
> 'events.name.v1.seminars' --operation EQUALS --url
> tcp://localhost:61616
> image.png
> As you see the federated queue shows the message in 'Delivering'
> State . This does not look ideal and may cause issues in the
> furture as I understand .
>
> *broker2*
> .\artemis.cmd queue stat --field ADDRESS --value 'events.#'
> --operation EQUALS --url tcp://localhost:61617
> image.png
> The messages from deferated queue shown as ACKED in consumer side .
>
--
Tim Bish
Re: Need help with federation setup with ActiveMq
Posted by Saju Daniel <ds...@gmail.com>.
Thanks a lot Tim . The config with ackBatchSize indeed worked .
I saw the reference to this parameter in the doc but thought this might be
not relevant to our setup .
[|
[Federation](https://activemq.apache.org/components/artemis/documentation/latest/federation.html)[activemq.apache.org](https://activemq.apache.org/components/artemis/documentation/latest/federation.html)|
[](https://activemq.apache.org/components/artemis/documentation/latest/federation.html)
---|---
](https://activemq.apache.org/components/artemis/documentation/latest/federation.html)
Best regards,
Saju Daniel
> On 1. Jul 2024, at 20:53, Timothy Bish <ta...@gmail.com> wrote:
>
>
> On 6/26/24 06:56, Saju Daniel wrote:
>
>
>> Hello,
>
>
>>
>
>
>> Just a gentle reminder. The issue is kind of critical for us to implement
federation on our setup .
>
>
>> Please let me know if you need more information on the problem.
>
>
>>
>
>
> After talking to Justin Bertram about some core client details I tried your
> setup and it appears that setting the Core client ackBatchSize value to
> something smaller than the default causes your test to work as expected.
>
> The connector can be configured using URI like:
>
> <connector
> name="europe-01-connector">tcp://0.0.0.0:61616?ackBatchSize=100</connector>
>
> Your testing is not filling the default window and so the client has not
> sent the acknowledgements.
>
>
>
>> Regards,
>
>
>> Saju
>
>
>>
>
>
>>
>
>
>> On Tue, 25 Jun 2024 at 16:50, Saju Daniel <ds...@gmail.com> wrote:
>
>
>>
>
>
>> Hello Tim ,
>
>
>>
>
>
>> The issue seems to be easy to reproduce. Nevertheless I am adding
>
>
>> the steps and configuration I used for my tests .
>
>
>> It would be great if you could kindly review the configuration.
>
>
>> These steps can be also used to create a bug report if needed .
>
>
>>
>
>
>> 1\. Install activeMq 2.35 and create 2 single node brokers
>
>
>> representing the EU(broker1) and USA(broker2) cluster.
>
>
>>
>
>
>> .\artemis create ../broker2;.\artemis create ../broker2
>
>
>>
>
>
>> 2\. Modify the broker.xml to add the federation configuration on
>
>
>> both the brokers. Attached the broker.xml files on each setup.
>
>
>> Since I am running the setup on same host I have adjusted the port
>
>
>> to avoid conflict
>
>
>>
>
>
>> 3\. Start both the brokers.
>
>
>>
>
>
>> 4\. Start the consumer on broker2
>
>
>>
>
>
>> .\artemis.cmd consumer --destination
>
>
>> events.#::audit-trail-shared.multicast --url tcp://0.0.0.0:61617
>
>
>> <http://0.0.0.0:61617>
>
>
>>
>
>
>> 5\. Create the producer on broker1
>
>
>>
>
>
>> .\artemis.cmd queue create --url tcp://0.0.0.0:61616
>
>
>> <http://0.0.0.0:61616> \--address events.name.v1.seminars --name
>
>
>> test --multicast --durable Y --purge-on-no-consumers N
>
>
>> \--auto-create-address Y
>
>
>>
>
>
>> 6\. Check the queue status on broker1. The federated queue is
>
>
>> created on the broker1
>
>
>>
>
>
>> .\artemis.cmd queue stat --field ADDRESS --value
>
>
>> 'events.name.v1.seminars' --operation EQUALS --url
>
>
>> tcp://localhost:61616
>
>
>> image.png
>
>
>>
>
>
>> 7\. Create a jms_client to send messages using multicast route .
>
>
>> (jms_client.zip) attached .
>
>
>>
>
>
>> 8\. Compile and execute the program to send multicast message on
>
>
>> the address events.name.v1.seminars
>
>
>>
>
>
>> mvn compile exec:java
>
>
>> mvn exec:java
>
>
>>
>
>
>> 9\. Check the message queue on broker1 and broker2
>
>
>>
>
>
>> *broker1*
>
>
>> .\artemis.cmd queue stat --field ADDRESS --value
>
>
>> 'events.name.v1.seminars' --operation EQUALS --url
>
>
>> tcp://localhost:61616
>
>
>> image.png
>
>
>> As you see the federated queue shows the message in 'Delivering'
>
>
>> State . This does not look ideal and may cause issues in the
>
>
>> furture as I understand .
>
>
>>
>
>
>> *broker2*
>
>
>> .\artemis.cmd queue stat --field ADDRESS --value 'events.#'
>
>
>> \--operation EQUALS --url tcp://localhost:61617
>
>
>> image.png
>
>
>> The messages from deferated queue shown as ACKED in consumer side .
>
>
>>
>
>
>
> \--
> Tim Bish
>