ActiveMQ
  1. ActiveMQ
  2. AMQ-3544

Rebalance does not work well(reproductive)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: 5.5.0
    • Fix Version/s: None
    • Component/s: Broker, JMS client
    • Labels:

      Description

      Assuming there are two networked brokers A and B in both direction and enable both brokers to rebalance client via three properties, updateClusterClients, updateClusterClientsOnRemove and rebalanceClusterClients.

      Now setting up a client whose broker url is Broker A to connect to Broker A and make sure the client has connected to Broker A via log information(you can change the log level to be debug level).

      Shutdown Broker A and expect for that the client will failover to Broker B but it will try to connect Brork A continually and does not know there is Broker B available at all!

        Activity

        Hide
        Timothy Bish added a comment -

        Could not reproduce this. There have been several additional fixes in this area lately so recommend you try a current SHNAPSHOT. If the problem persists you can reopen this issue.

        Show
        Timothy Bish added a comment - Could not reproduce this. There have been several additional fixes in this area lately so recommend you try a current SHNAPSHOT. If the problem persists you can reopen this issue.
        Hide
        Dejan Bosanac added a comment -

        Hi, this is now changed with some commits made for https://issues.apache.org/jira/browse/AMQ-3685

        It'd be great if you could test the latest snapshot and see how it works for you

        Show
        Dejan Bosanac added a comment - Hi, this is now changed with some commits made for https://issues.apache.org/jira/browse/AMQ-3685 It'd be great if you could test the latest snapshot and see how it works for you
        Hide
        Tomer Bashan added a comment -

        figured out the problem (at list on my env)
        when a broker updates another broker that it is up (or down), it identifies itself by the server name.
        once the server name of all brokers was added to /etc/hosts on the client side, all was well

        I guess this is bad practice, and the broker should identify itself by ip and not by hostname

        I was running activeMQ 5.5.1 on ubuntu 10.4

        Show
        Tomer Bashan added a comment - figured out the problem (at list on my env) when a broker updates another broker that it is up (or down), it identifies itself by the server name. once the server name of all brokers was added to /etc/hosts on the client side, all was well I guess this is bad practice, and the broker should identify itself by ip and not by hostname I was running activeMQ 5.5.1 on ubuntu 10.4
        Hide
        Rob Davies added a comment -

        I can't reproduce this either with the test case

        Show
        Rob Davies added a comment - I can't reproduce this either with the test case
        Hide
        SuoNayi added a comment -

        Unit test for reproducting the issue.

        Show
        SuoNayi added a comment - Unit test for reproducting the issue.
        Hide
        SuoNayi added a comment -

        ok,I will reconstruct the test case to make the issue clear.
        As far as I know, when a broker is stopping it will close all bridges with others and notify it's current connected brokers to clients,but those current connected brokers are itself now.The clients will be updated by the url of the broker which is stopped ,so the clients will not know those active broker url.

        Show
        SuoNayi added a comment - ok,I will reconstruct the test case to make the issue clear. As far as I know, when a broker is stopping it will close all bridges with others and notify it's current connected brokers to clients,but those current connected brokers are itself now.The clients will be updated by the url of the broker which is stopped ,so the clients will not know those active broker url.
        Hide
        Timothy Bish added a comment -

        I was never able to reproduce the issue with the test case given. You might want to try and tweak it somewhat to see if you can make the issue appear, in any event, adding the issue here and checking the grant license to Apache box will allow us to include it in the unit tests should we find a way to reproduce and fix the issue.

        Show
        Timothy Bish added a comment - I was never able to reproduce the issue with the test case given. You might want to try and tweak it somewhat to see if you can make the issue appear, in any event, adding the issue here and checking the grant license to Apache box will allow us to include it in the unit tests should we find a way to reproduce and fix the issue.
        Hide
        SuoNayi added a comment -

        Ok,I have prepared a unit test AMQ3544Test.java and sent it to your gmail inbox.

        Show
        SuoNayi added a comment - Ok,I have prepared a unit test AMQ3544Test.java and sent it to your gmail inbox.
        Hide
        Timothy Bish added a comment -

        You can have a look at the FailoverClusterTest.java and see if you can create a case that matches the trouble you are seeing.

        Show
        Timothy Bish added a comment - You can have a look at the FailoverClusterTest.java and see if you can create a case that matches the trouble you are seeing.
        Hide
        SuoNayi added a comment -

        Is anybody there?
        Is there nobody get into this trouble?

        Show
        SuoNayi added a comment - Is anybody there? Is there nobody get into this trouble?

          People

          • Assignee:
            Unassigned
            Reporter:
            SuoNayi
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development