directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: Supporting LDAP HA client
Date Mon, 16 Apr 2018 17:23:32 GMT

> 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
View raw message