Qpid
  1. Qpid
  2. QPID-3220

Specifying connection url option failover='singlebroker' causes the wrong failover policy to be used

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10
    • Fix Version/s: 0.11
    • Component/s: Java Client
    • Labels:
      None

      Description

      If the user specifies the option failover='singlebroker' in the connection URL, a coding error in FailoverPolicy.java means that the client actually elects to use FailoverRoundRobinServers policy rather than FailoverSingleServer.

      For example, the following URL will cause the client to use the round-robin policy.

      amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672?retries='50'&connectdelay='5000''&failover='singlebroker'
      

      Furthermore, as the logic FailoverRoundRobinServers.getNextBrokerDetails means that if the roundrobin policy is used with a brokerlist containing one broker, connectdelay is never applied, this defect also means that if a user passes failover='singlebroker' with a broker list containing one entry, connectdelay is ignored. This can give the appearance that server reconnection is broken as the client can spin through thousands of retries before then broker has chance to restart.

      To workaround this issue, the user can omit the failover option from the URL and let the defaulting within FailoverPolicy class choose FailoverSingleServer if the brokerlist contains one entry, or FailoverRoundRobinServers if the list contains more than one.

      Client will default to singlebroker policy:

      amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672'
      

      Client will default to roundrobin policy:

      amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672;tcp://localhost:5672'
      

        Activity

        Keith Wall created issue -
        Keith Wall made changes -
        Field Original Value New Value
        Description If the user specifies the option failover='singlebroker' in the connection URL, an coding error in FailoverPolicy.java means that the client actually elects to use FailoverRoundRobinServers policy rather than FailoverSingleServer.

        For example, the following URL will cause the client to use the round-robin policy.

        {code}
        amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672?retries='50'&connectdelay='5000''&failover='singlebroker'
        {code}

        Furthermore, as the logic FailoverRoundRobinServers.getNextBrokerDetails means that if the roundrobin policy is used with a brokerlist containing *one broker*, connectdelay is never applied, this defect also means that if a user passes failover='singlebroker' with a broker list containing one entry, connectdelay is ignored. This can give the appearance that server reconnection is broken as the client can spin through thousands of retries before then broker has chance to restart.

        To workaround this issue, the user can omit the failover option from the URL and let the defaulting within FailoverPolicy class choose FailoverSingleServer if the brokerlist contains one entry, or FailoverRoundRobinServers if the list contains more than one.


        Client will default to singlebroker policy:

        {code}
        amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672'
        {code}

        Client will default to roundrobin policy:

        {code}
        amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672;tcp://localhost:5672'
        {code}


        If the user specifies the option failover='singlebroker' in the connection URL, a coding error in FailoverPolicy.java means that the client actually elects to use FailoverRoundRobinServers policy rather than FailoverSingleServer.

        For example, the following URL will cause the client to use the round-robin policy.

        {code}
        amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672?retries='50'&connectdelay='5000''&failover='singlebroker'
        {code}

        Furthermore, as the logic FailoverRoundRobinServers.getNextBrokerDetails means that if the roundrobin policy is used with a brokerlist containing *one broker*, connectdelay is never applied, this defect also means that if a user passes failover='singlebroker' with a broker list containing one entry, connectdelay is ignored. This can give the appearance that server reconnection is broken as the client can spin through thousands of retries before then broker has chance to restart.

        To workaround this issue, the user can omit the failover option from the URL and let the defaulting within FailoverPolicy class choose FailoverSingleServer if the brokerlist contains one entry, or FailoverRoundRobinServers if the list contains more than one.


        Client will default to singlebroker policy:

        {code}
        amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672'
        {code}

        Client will default to roundrobin policy:

        {code}
        amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672;tcp://localhost:5672'
        {code}


        Keith Wall made changes -
        Assignee Keith Wall [ k-wall ]
        Keith Wall made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Keith Wall made changes -
        Robbie Gemmell made changes -
        Assignee Keith Wall [ k-wall ] Robbie Gemmell [ gemmellr ]
        Robbie Gemmell made changes -
        Status In Progress [ 3 ] Ready To Review [ 10006 ]
        Robbie Gemmell made changes -
        Fix Version/s 0.11 [ 12316272 ]
        Affects Version/s 0.9 [ 12315382 ]
        Affects Version/s 0.8 [ 12315477 ]
        Affects Version/s 0.7 [ 12314455 ]
        Affects Version/s 0.6 [ 12313728 ]
        Robbie Gemmell made changes -
        Status Ready To Review [ 10006 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Robbie Gemmell
            Reporter:
            Keith Wall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development