directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yudhi Karunia Surtan <yudh...@apache.org>
Subject Re: Supporting LDAP HA client
Date Mon, 16 Apr 2018 18:02:02 GMT
Hi Shawn,

I did a comparison between ldaptive and fortress, but it still need time
for me to understand completely of what they are doing. The only thing I
realize that they are not using common pool for pooling, but they create
their own pooling mechanism.

My idea is a bit different with ldaptive implementation which they mostly
do the check before giving the connection. For fortress or ldap-api i
propose that the the client need to understand which node is healthy and
give only the health one or thrown exception if all bad.

I still don't know how big the changes will be but i think better if I try
to put it on the code first and later all of you can give a feedback about
it. It might changes the current LdapConnectionProvider class.

Do you have an idea how should ldap health check should be?
Is that necessary to use bind command or something like telnet should work?


On Tue, Apr 17, 2018, 00:23 Shawn McKinney <smckinney@apache.org> wrote:

>
> > On Apr 16, 2018, at 10:27 AM, Yudhi Karunia Surtan <yudhiks@apache.org>
> wrote:
> >
> > Hi Shawn, for ldaptive you can see at the page for urls and connection
> > strategies section.
>
> Ah yes found it:
>
> ***
>
> All the providers in ldaptive will attempt to parse this form correctly.
> If multiple URLs are provided you can specify a client side connection
> strategy to control the behavior if a connection cannot be established.
>
> Connection Strategies:
>
> Name    Behavior
> DEFAULT no action, behavior dictated by the provider
> ACTIVE_PASSIVE  attempt each URL in the order provided for each
> connection; the first URL is always used unless it fails
> ROUND_ROBIN     attempt the next URL in the order provided for each
> connection; URLs are rotated regardless of connection success or failure
> RANDOM  attempt a random URL; useful for stateless implementations
> ConnectionConfig connConfig = new ConnectionConfig("ldap://
> directory-1.ldaptive.org ldap://directory-2.ldaptive.org");
> connConfig.setConnectionStrategy(new RoundRobinConnectionStrategy());
> DefaultConnectionFactory connFactory = new
> DefaultConnectionFactory(connConfig);
> Connection conn = connFactory.getConnection();
>
> ***
>
> >
> > On Apr 16, 2018, at 10:27 AM, Yudhi Karunia Surtan <yudhiks@apache.org>
> wrote:
> >
> > In my opinion it should be at ldap-api, because other can use it too.
> > Meanwhile if fortress do it, then i afraid people think that it only used
> > by fortress.
> >
> > What do u think Shawn?
>
> I believe your idea has merit and agree that it should be at the api level.
>
> So, the next step is to figure out what exactly must change.
>
> In fortress the LdapConnectionProvider class would be updated to use the
> new functionality.  We’d extend the config props to except a list of host
> names/ips.
>
> Fairly trivial changes.
>
> What should the API look like, where would the changes need to be made.
> Do we extend a class, create a new one, etc?  We should have some idea of
> what changes need to be made on the api side, teh level of complexity, and
> estimated time.
>
> Have no idea how big of change this would be but it’s needs to figured
> out.
>
> We also must be prepared to make the changes (to the api) ourselves.
>
> I know there are plans being made for a new api release but doubt that
> we’d be able to sneak something this big in.
>
>
> Shawn
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message