On Sat, 9 Nov 2024 at 03:35, Fisher, Daniel <dfis...@vt.edu> wrote: > > On Nov 8, 2024, at 1:05 AM, kkalev <kka...@gmail.com> wrote: > > Thanks a lot for the clarification. The planned feature will certainly be > nice in order to be certain that the "passive" LDAP server will be cycled > out after a certain period of time. Cycling out based on idle timeout will > be hard in servers with heavy load. > > > You can’t prune connections during heavy load. If your entire pool is > occupied with servicing requests you should expect those connections to > remain until the load subsides. That is, the implementation only considers > _available_ connections for pruning. Not sure if that’s what you meant, but > I wanted to clarify. > Sorry for the delayed response!
If "active" server went offline, we transitioned to "passive" and then "active" went back online, one could argue that we want to actually use the active server and not keep connections to passive until every each one reaches an idle timeout. Transitioning would be a problem if the active server was not available. I understand that this is a border line philosophical discussion and not a purely technical one. Imagine that the "Active" server might be our write master while our "passive" a read-only replica with limited resources which sometimes lags the master. So we would like to always use the "active" one if possible and use the "passive" only during outages with automatic and relatively quick failover when the primary is back online. > > I think it would be helpful to add what you wrote in the documentation for > the connection-strategy LDAP option since it is a bit counter intuitive (at > least with respect to what one would expect from an "ACTIVE_PASSIVE" > label). I also went through the ldaptive documentation and could not find > any helpful hint there as well. > > > I’ll take a pass over the documentation, it can always be improved. Note > that the connectionStrategy and the pruneStrategy are currently decoupled. > The way that connections are created has no bearing on how they are > selected for removal. > > The connection strategies should work as expected when *not* using a > connection pool (and performing a new connection for every request). I > guess that I was expecting automatic failover to the "ACTIVE" LDAP server > due to the validation functionality of the ldaptive connection pooling: > https://www.ldaptive.org/docs/guide/connections/pooling.html > > > Can you elaborate a bit more on how you would prefer this type of feature > to work? Specifically, would you want connections made to “passive” URLs to > be pruned immediately or should they just be the first connections that are > pruned if their idle timeout has occurred? > If active and passive are both available it might be preferable to "open a new connection to active, prune one connection to passive until no more connections to passive". > > —Daniel Fisher > > -- > - Website: https://apereo.github.io/cas > - List Guidelines: https://goo.gl/1VRrw7 > - Contributions: https://goo.gl/mh7qDG > --- > You received this message because you are subscribed to a topic in the > Google Groups "CAS Community" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/apereo.org/d/topic/cas-user/390ZR4y345c/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > cas-user+unsubscr...@apereo.org. > To view this discussion visit > https://groups.google.com/a/apereo.org/d/msgid/cas-user/C0AB73E2-D2AC-41B1-A991-531A0F68E255%40vt.edu > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/C0AB73E2-D2AC-41B1-A991-531A0F68E255%40vt.edu?utm_medium=email&utm_source=footer> > . > -- - Website: https://apereo.github.io/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CACSOpgSn-t4tem7AGUBQBfHvX4x9Dkc5taPM5u_HE_6gxteQwA%40mail.gmail.com.
