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

Reply via email to