| 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 .
Best regards,On 1. Jul 2024, at 20:53, Timothy Bish <tabish...@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 <dsa...@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
|
