Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-14050

LDAP should reestablish connection to the orignal server after it has recovered

    Details

    • Sprint:
      AM Sustaining Sprint 57, AM Sustaining Sprint 58, AM Sustaining Sprint 59
    • Story Points:
      5
    • Needs backport:
      No
    • Support Ticket IDs:
    • Verified Version/s:
    • Needs QA verification:
      Yes
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      When a LDAP server stops responding and a new connection is made there is an expectation that if the orignal server is brought back online, that this connection would be reestablished. 

      From what we are seeing when we reach the max pool size though we are not seeing any of the connections dropped to allow for the orignal server to start serving requests. 

      This cause a scenario where when a server goes down or becomes unresponsive it will end up with no load, and there is no automatic way to allow the Load to redistribute among the LDAP servers. 

      How to reproduce the issue

      Details steps outlining how to recreate the issue (remove this text)

      1. AM configured to point to 3 LDAP servers behind a load balancer and a connection pool size for simplicity of 10. 
      2. Start AM and have a balanced load of connections to LDAP servers
      3. Stop/disconnect LDAP server 1. This should cause LDAP 2 and 3 to now have all 10 connections 
      4. Restart LDAP server1
      Expected behaviour
      When LDAP1 comes back online that it's orignal connections would be opened again so there would be a balanced number of connections
      Current behaviour
      LDAP2 and LDAP3 will continue to have all of the connections and no new connections will goto LDAP1 unless the a connection breaks or a server is marked as down. 

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                lawrence.yarham Lawrence Yarham
                Reporter:
                william.hepler William Hepler
              • Votes:
                1 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: