You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fortress@directory.apache.org by Yudhi Karunia Surtan <yu...@apache.org> on 2018/04/16 04:19:57 UTC
Supporting LDAP HA client
Hi Guys,
Do we have a plan to support ldap HA client?
I think it is possible to extend
"org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory" and
make some connection strategy similar like
http://www.ldaptive.org/docs/guide/connections.html.
What do you guys think about this?
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Dear fortress Commiters,
Please postpone the release related to the HA LDAP connection pool.
For the round robin strategy, I found a mistake where the request has been
balanced to the given nodes, but after killing one of ldap somehow my logic
failed.
I think I need to again looks how manage the closed connection works on it.
Also for the perf test, round robin strategy give more response time than
previous single connection.
On Wed, Apr 25, 2018, 20:18 Yudhi Karunia Surtan <yu...@apache.org> wrote:
> Hi shawn,
>
> Ok. Will do the internal release using different repository and change the
> pom file at my local repository and once fortress done with released, I
> will again upgrade my IAM into the release version from community.
>
> Thanks and soon will give you the report for the perf test result once it
> is done.
>
>
> On Wed, Apr 25, 2018, 19:52 Shawn McKinney <sm...@apache.org> wrote:
>
>>
>> > On Apr 24, 2018, at 11:50 PM, Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> >
>> > I just commit a new code and test with 2 ldap with round robin
>> connection
>> > strategy.
>> > Bellow are the scenarios:
>> >
>> > - start commander with 2 ldap and shut and start one to another.
>> > - start commander with 1 ldap and start other ldap defined at the
>> > configuration.
>> >
>> > and the result are great both scenarios working well without disturbing
>> the
>> > user interactions, so the HA working smooth.
>>
>> Hey Yudhi, that’s good news.
>>
>> >
>> > On Apr 24, 2018, at 11:50 PM, Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> >
>> > I would like to release this version internally and deploy along with
>> CAS
>> > at my production at Mei 15 and before that i would like to do some
>> > performance test to make sure the logic able to perform in production
>> later.
>> >
>> > Do we have a plan for releasing new fortress version before Mei 15?
>> > If it is yes then i will not using my own version and follow the main
>> > community release line and do the perf test on that version.
>>
>> Sounds like a good plan. This is good timing actually as I was just
>> getting ready to announce plans for a new release - 2.0.1. We can hold off
>> until May 15. Keep us apprised on how it goes.
>>
>> Shawn
>>
>>
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Hi shawn,
Ok. Will do the internal release using different repository and change the
pom file at my local repository and once fortress done with released, I
will again upgrade my IAM into the release version from community.
Thanks and soon will give you the report for the perf test result once it
is done.
On Wed, Apr 25, 2018, 19:52 Shawn McKinney <sm...@apache.org> wrote:
>
> > On Apr 24, 2018, at 11:50 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > I just commit a new code and test with 2 ldap with round robin connection
> > strategy.
> > Bellow are the scenarios:
> >
> > - start commander with 2 ldap and shut and start one to another.
> > - start commander with 1 ldap and start other ldap defined at the
> > configuration.
> >
> > and the result are great both scenarios working well without disturbing
> the
> > user interactions, so the HA working smooth.
>
> Hey Yudhi, that’s good news.
>
> >
> > On Apr 24, 2018, at 11:50 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > I would like to release this version internally and deploy along with CAS
> > at my production at Mei 15 and before that i would like to do some
> > performance test to make sure the logic able to perform in production
> later.
> >
> > Do we have a plan for releasing new fortress version before Mei 15?
> > If it is yes then i will not using my own version and follow the main
> > community release line and do the perf test on that version.
>
> Sounds like a good plan. This is good timing actually as I was just
> getting ready to announce plans for a new release - 2.0.1. We can hold off
> until May 15. Keep us apprised on how it goes.
>
> Shawn
>
>
Re: Supporting LDAP HA client
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 24, 2018, at 11:50 PM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> I just commit a new code and test with 2 ldap with round robin connection
> strategy.
> Bellow are the scenarios:
>
> - start commander with 2 ldap and shut and start one to another.
> - start commander with 1 ldap and start other ldap defined at the
> configuration.
>
> and the result are great both scenarios working well without disturbing the
> user interactions, so the HA working smooth.
Hey Yudhi, that’s good news.
>
> On Apr 24, 2018, at 11:50 PM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> I would like to release this version internally and deploy along with CAS
> at my production at Mei 15 and before that i would like to do some
> performance test to make sure the logic able to perform in production later.
>
> Do we have a plan for releasing new fortress version before Mei 15?
> If it is yes then i will not using my own version and follow the main
> community release line and do the perf test on that version.
Sounds like a good plan. This is good timing actually as I was just getting ready to announce plans for a new release - 2.0.1. We can hold off until May 15. Keep us apprised on how it goes.
Shawn
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Hi guys,
I just commit a new code and test with 2 ldap with round robin connection
strategy.
Bellow are the scenarios:
- start commander with 2 ldap and shut and start one to another.
- start commander with 1 ldap and start other ldap defined at the
configuration.
and the result are great both scenarios working well without disturbing the
user interactions, so the HA working smooth.
I would like to release this version internally and deploy along with CAS
at my production at Mei 15 and before that i would like to do some
performance test to make sure the logic able to perform in production later.
Do we have a plan for releasing new fortress version before Mei 15?
If it is yes then i will not using my own version and follow the main
community release line and do the perf test on that version.
Yudhi Karunia Surtan
On Fri, Apr 20, 2018 at 12:22 AM, Yudhi Karunia Surtan <yu...@apache.org>
wrote:
> Well, this is actually only a draft.
> With this, I hope i can drag more idea from you guys.
> Please share if you guys have any input.
> I will try to modified "LdapConnectionProvider" tomorrow and use the
> class that I made and see how it works.
> I will update you guys about the experiment result at end of tomorrow.
>
>
> Yudhi Karunia Surtan
>
>
> On Thu, Apr 19, 2018, 21:20 Shawn McKinney <sm...@apache.org> wrote:
>
>> I just now glanced at the code Yudhi, will need to test it, but first
>> glance looks pretty good. Your approach of how to integrate the change is
>> good.
>>
>> Shawn
>>
>> > On Apr 19, 2018, at 7:45 AM, Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> >
>> > Hi Guys,
>> >
>> > After trying to understand better about commons-pool,
>> > apache-directory-ldap-api and fortress.
>> > I've come with a draft solution at branch "trivial/support-ha-client"
>> >
>> > I introduce 2 class which
>> >
>> > src/main/java/org/apache/directory/fortress/core/ldap/
>> HAConnectionStrategy.java
>> > src/main/java/org/apache/directory/fortress/core/ldap/
>> LdapHAConnectionPool.java
>> >
>> > with this i try to minimize the existing changes at
>> LdapConnectionProvider
>> > class.
>> >
>> > the idea is by changing :
>> > adminPool = new LdapConnectionPool( poolFactory );
>> >
>> > into :
>> >
>> > adminPool = new LdapHAConnectionPool( poolFactory );
>> >
>> > at LdapConnectionProvider class.
>> >
>> > What do you guys think about the changes i made at those branch?
>> >
>> >
>> >
>> >
>> > Yudhi Karunia Surtan
>> >
>> >
>> >
>> > On Tue, Apr 17, 2018 at 10:42 PM, Yudhi Karunia Surtan <
>> yudhiks@apache.org>
>> > wrote:
>> >
>> >> Ok shawn..
>> >> I think it is possible to use keyedpool too, because it able act as
>> >> arbiter. Let me finish this thing and update u once after it finished.
>> >>
>> >> On Tue, Apr 17, 2018, 22:18 Shawn McKinney <sm...@apache.org>
>> wrote:
>> >>
>> >>>
>> >>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <
>> yudhiks@apache.org>
>> >>> wrote:
>> >>>>
>> >>>> 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.
>> >>>
>> >>> Agreed
>> >>>
>> >>>>
>> >>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <
>> yudhiks@apache.org>
>> >>> wrote:
>> >>>>
>> >>>> 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.
>> >>>
>> >>> That sounds like a good plan to me.
>> >>>
>> >>>>
>> >>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <
>> yudhiks@apache.org>
>> >>> wrote:
>> >>>>
>> >>>> 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?
>> >>>
>> >>> I’d think the health check’s purpose is to make sure that server is
>> >>> responding in as lightweight a way as possible. Bind is too heavy.
>> >>> Telnet’s a possibility, but this is something we’ll vet with on the
>> dev’prs
>> >>> list. For your experiment, anything will work knowing it may change
>> later.
>> >>>
>> >>> Thanks,
>> >>> Shawn
>> >>>
>> >>>
>> >>>
>> >>>
>>
>>
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Well, this is actually only a draft.
With this, I hope i can drag more idea from you guys.
Please share if you guys have any input.
I will try to modified "LdapConnectionProvider" tomorrow and use the class
that I made and see how it works.
I will update you guys about the experiment result at end of tomorrow.
Yudhi Karunia Surtan
On Thu, Apr 19, 2018, 21:20 Shawn McKinney <sm...@apache.org> wrote:
> I just now glanced at the code Yudhi, will need to test it, but first
> glance looks pretty good. Your approach of how to integrate the change is
> good.
>
> Shawn
>
> > On Apr 19, 2018, at 7:45 AM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > Hi Guys,
> >
> > After trying to understand better about commons-pool,
> > apache-directory-ldap-api and fortress.
> > I've come with a draft solution at branch "trivial/support-ha-client"
> >
> > I introduce 2 class which
> >
> >
> src/main/java/org/apache/directory/fortress/core/ldap/HAConnectionStrategy.java
> >
> src/main/java/org/apache/directory/fortress/core/ldap/LdapHAConnectionPool.java
> >
> > with this i try to minimize the existing changes at
> LdapConnectionProvider
> > class.
> >
> > the idea is by changing :
> > adminPool = new LdapConnectionPool( poolFactory );
> >
> > into :
> >
> > adminPool = new LdapHAConnectionPool( poolFactory );
> >
> > at LdapConnectionProvider class.
> >
> > What do you guys think about the changes i made at those branch?
> >
> >
> >
> >
> > Yudhi Karunia Surtan
> >
> >
> >
> > On Tue, Apr 17, 2018 at 10:42 PM, Yudhi Karunia Surtan <
> yudhiks@apache.org>
> > wrote:
> >
> >> Ok shawn..
> >> I think it is possible to use keyedpool too, because it able act as
> >> arbiter. Let me finish this thing and update u once after it finished.
> >>
> >> On Tue, Apr 17, 2018, 22:18 Shawn McKinney <sm...@apache.org>
> wrote:
> >>
> >>>
> >>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yudhiks@apache.org
> >
> >>> wrote:
> >>>>
> >>>> 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.
> >>>
> >>> Agreed
> >>>
> >>>>
> >>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yudhiks@apache.org
> >
> >>> wrote:
> >>>>
> >>>> 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.
> >>>
> >>> That sounds like a good plan to me.
> >>>
> >>>>
> >>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yudhiks@apache.org
> >
> >>> wrote:
> >>>>
> >>>> 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?
> >>>
> >>> I’d think the health check’s purpose is to make sure that server is
> >>> responding in as lightweight a way as possible. Bind is too heavy.
> >>> Telnet’s a possibility, but this is something we’ll vet with on the
> dev’prs
> >>> list. For your experiment, anything will work knowing it may change
> later.
> >>>
> >>> Thanks,
> >>> Shawn
> >>>
> >>>
> >>>
> >>>
>
>
Re: Supporting LDAP HA client
Posted by Shawn McKinney <sm...@apache.org>.
I just now glanced at the code Yudhi, will need to test it, but first glance looks pretty good. Your approach of how to integrate the change is good.
Shawn
> On Apr 19, 2018, at 7:45 AM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> Hi Guys,
>
> After trying to understand better about commons-pool,
> apache-directory-ldap-api and fortress.
> I've come with a draft solution at branch "trivial/support-ha-client"
>
> I introduce 2 class which
>
> src/main/java/org/apache/directory/fortress/core/ldap/HAConnectionStrategy.java
> src/main/java/org/apache/directory/fortress/core/ldap/LdapHAConnectionPool.java
>
> with this i try to minimize the existing changes at LdapConnectionProvider
> class.
>
> the idea is by changing :
> adminPool = new LdapConnectionPool( poolFactory );
>
> into :
>
> adminPool = new LdapHAConnectionPool( poolFactory );
>
> at LdapConnectionProvider class.
>
> What do you guys think about the changes i made at those branch?
>
>
>
>
> Yudhi Karunia Surtan
>
>
>
> On Tue, Apr 17, 2018 at 10:42 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
>
>> Ok shawn..
>> I think it is possible to use keyedpool too, because it able act as
>> arbiter. Let me finish this thing and update u once after it finished.
>>
>> On Tue, Apr 17, 2018, 22:18 Shawn McKinney <sm...@apache.org> wrote:
>>
>>>
>>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
>>> wrote:
>>>>
>>>> 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.
>>>
>>> Agreed
>>>
>>>>
>>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
>>> wrote:
>>>>
>>>> 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.
>>>
>>> That sounds like a good plan to me.
>>>
>>>>
>>>> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
>>> wrote:
>>>>
>>>> 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?
>>>
>>> I’d think the health check’s purpose is to make sure that server is
>>> responding in as lightweight a way as possible. Bind is too heavy.
>>> Telnet’s a possibility, but this is something we’ll vet with on the dev’prs
>>> list. For your experiment, anything will work knowing it may change later.
>>>
>>> Thanks,
>>> Shawn
>>>
>>>
>>>
>>>
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Hi Guys,
After trying to understand better about commons-pool,
apache-directory-ldap-api and fortress.
I've come with a draft solution at branch "trivial/support-ha-client"
I introduce 2 class which
src/main/java/org/apache/directory/fortress/core/ldap/HAConnectionStrategy.java
src/main/java/org/apache/directory/fortress/core/ldap/LdapHAConnectionPool.java
with this i try to minimize the existing changes at LdapConnectionProvider
class.
the idea is by changing :
adminPool = new LdapConnectionPool( poolFactory );
into :
adminPool = new LdapHAConnectionPool( poolFactory );
at LdapConnectionProvider class.
What do you guys think about the changes i made at those branch?
Yudhi Karunia Surtan
On Tue, Apr 17, 2018 at 10:42 PM, Yudhi Karunia Surtan <yu...@apache.org>
wrote:
> Ok shawn..
> I think it is possible to use keyedpool too, because it able act as
> arbiter. Let me finish this thing and update u once after it finished.
>
> On Tue, Apr 17, 2018, 22:18 Shawn McKinney <sm...@apache.org> wrote:
>
>>
>> > On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> >
>> > 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.
>>
>> Agreed
>>
>> >
>> > On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> >
>> > 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.
>>
>> That sounds like a good plan to me.
>>
>> >
>> > On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> >
>> > 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?
>>
>> I’d think the health check’s purpose is to make sure that server is
>> responding in as lightweight a way as possible. Bind is too heavy.
>> Telnet’s a possibility, but this is something we’ll vet with on the dev’prs
>> list. For your experiment, anything will work knowing it may change later.
>>
>> Thanks,
>> Shawn
>>
>>
>>
>>
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Ok shawn..
I think it is possible to use keyedpool too, because it able act as
arbiter. Let me finish this thing and update u once after it finished.
On Tue, Apr 17, 2018, 22:18 Shawn McKinney <sm...@apache.org> wrote:
>
> > On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > 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.
>
> Agreed
>
> >
> > On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > 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.
>
> That sounds like a good plan to me.
>
> >
> > On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > 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?
>
> I’d think the health check’s purpose is to make sure that server is
> responding in as lightweight a way as possible. Bind is too heavy.
> Telnet’s a possibility, but this is something we’ll vet with on the dev’prs
> list. For your experiment, anything will work knowing it may change later.
>
> Thanks,
> Shawn
>
>
>
>
Re: Supporting LDAP HA client
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> 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.
Agreed
>
> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> 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.
That sounds like a good plan to me.
>
> On Apr 16, 2018, at 1:02 PM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> 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?
I’d think the health check’s purpose is to make sure that server is responding in as lightweight a way as possible. Bind is too heavy. Telnet’s a possibility, but this is something we’ll vet with on the dev’prs list. For your experiment, anything will work knowing it may change later.
Thanks,
Shawn
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
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 <sm...@apache.org> wrote:
>
> > On Apr 16, 2018, at 10:27 AM, Yudhi Karunia Surtan <yu...@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 <yu...@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
>
>
>
>
Re: Supporting LDAP HA client
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 16, 2018, at 10:27 AM, Yudhi Karunia Surtan <yu...@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 <yu...@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
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Hi Shawn, for ldaptive you can see at the page for urls and connection
strategies section.
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?
On Mon, Apr 16, 2018, 21:01 Shawn McKinney <sm...@apache.org> wrote:
>
> > On Apr 16, 2018, at 8:49 AM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > Thanks for your answer.
> > LDAP have the capability for replicate their entries to other ldap server
> > which is good.
> > However, things such as VM failure, network glitch might give bad effect
> to
> > the application. That is why i would like to try to implement our
> fortress
> > to become more reliable when meet those situation.
> >
> > As per my understanding, to face that trouble time I can choose by using
> > active passive connection type or round robin which each of them have
> pros
> > and cons.
>
> OK, we’re in agreement in what HA means — some sort of pool of ‘servers’,
> from a replicated network of ldap servers.
>
> Now, the next step is understanding how we’d accomplish this, as we’re
> both in agreement that it’s good and necessary.
>
> >
> > On Apr 16, 2018, at 8:49 AM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > With active passive, I think the implementation will more easy because
> once
> > 1 connection is not usable it just switch to other ldap server. Until all
> > server is not enable the throw the exception, but using this strategy it
> is
> > not possible to scale and balance the cpu load since only 1 active server
> > will be used.
> >
> > In other hand, using round robin is more complicated to be implement
> since
> > it should use some health check mechanism before it can decide which
> server
> > should receive the request, but the cpu load can be more fair for each of
> > ldap server.
> >
> > And of course the application should able to detect if the connection has
> > been recover and reuse the it if possible (depends on the strategy that I
> > explain above). With that the apps is not necessary to do a restart for
> > recover or instantiate the connection to ldap.
> >
> > Am I answering your question Shawn?
>
> Yes, except for one remaining. Where in the ldapative api reference did
> it mention one of these connection strategies? I’m somehow missing where
> they discussed it and how it works.
>
> Once we’ve reached agreement to proceed, we’ll need to figure out where
> the code resides. Will it be an extension that resides in fortress core,
> or do we convince the api team that this feature is good and necessary, and
> enlist their support.
>
> Shawn
>
>
>
>
Re: Supporting LDAP HA client
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 16, 2018, at 8:49 AM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> Thanks for your answer.
> LDAP have the capability for replicate their entries to other ldap server
> which is good.
> However, things such as VM failure, network glitch might give bad effect to
> the application. That is why i would like to try to implement our fortress
> to become more reliable when meet those situation.
>
> As per my understanding, to face that trouble time I can choose by using
> active passive connection type or round robin which each of them have pros
> and cons.
OK, we’re in agreement in what HA means — some sort of pool of ‘servers’, from a replicated network of ldap servers.
Now, the next step is understanding how we’d accomplish this, as we’re both in agreement that it’s good and necessary.
>
> On Apr 16, 2018, at 8:49 AM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> With active passive, I think the implementation will more easy because once
> 1 connection is not usable it just switch to other ldap server. Until all
> server is not enable the throw the exception, but using this strategy it is
> not possible to scale and balance the cpu load since only 1 active server
> will be used.
>
> In other hand, using round robin is more complicated to be implement since
> it should use some health check mechanism before it can decide which server
> should receive the request, but the cpu load can be more fair for each of
> ldap server.
>
> And of course the application should able to detect if the connection has
> been recover and reuse the it if possible (depends on the strategy that I
> explain above). With that the apps is not necessary to do a restart for
> recover or instantiate the connection to ldap.
>
> Am I answering your question Shawn?
Yes, except for one remaining. Where in the ldapative api reference did it mention one of these connection strategies? I’m somehow missing where they discussed it and how it works.
Once we’ve reached agreement to proceed, we’ll need to figure out where the code resides. Will it be an extension that resides in fortress core, or do we convince the api team that this feature is good and necessary, and enlist their support.
Shawn
Re: Supporting LDAP HA client
Posted by Yudhi Karunia Surtan <yu...@apache.org>.
Hi Shawn,
Thanks for your answer.
LDAP have the capability for replicate their entries to other ldap server
which is good.
However, things such as VM failure, network glitch might give bad effect to
the application. That is why i would like to try to implement our fortress
to become more reliable when meet those situation.
As per my understanding, to face that trouble time I can choose by using
active passive connection type or round robin which each of them have pros
and cons.
With active passive, I think the implementation will more easy because once
1 connection is not usable it just switch to other ldap server. Until all
server is not enable the throw the exception, but using this strategy it is
not possible to scale and balance the cpu load since only 1 active server
will be used.
In other hand, using round robin is more complicated to be implement since
it should use some health check mechanism before it can decide which server
should receive the request, but the cpu load can be more fair for each of
ldap server.
And of course the application should able to detect if the connection has
been recover and reuse the it if possible (depends on the strategy that I
explain above). With that the apps is not necessary to do a restart for
recover or instantiate the connection to ldap.
Am I answering your question Shawn?
Yudhi Karunia Surtan
On Mon, Apr 16, 2018, 20:27 Shawn McKinney <sm...@apache.org> wrote:
>
> > On Apr 15, 2018, at 11:19 PM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > Do we have a plan to support ldap HA client?
> >
> > I think it is possible to extend
> > "org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory" and
> > make some connection strategy similar like
> > http://www.ldaptive.org/docs/guide/connections.html.
> >
> > What do you guys think about this?
>
> Hi Yudhi, read the page, are you referring to the section 'Operation
> Retry’?
>
> Another question, what do you consider HA? I Remember the old netscape
> ldap api (as do others like python’s ldap3) allow the client to specify a
> server pool, which then enables the api to roundrobin, or some other
> protocol, to each server in attempt to find one that is active.
>
> To me this server pool is ‘HA'. But reading the doc, it seems this
> ldapative api (first I heard of this one) uses an approach where it will
> retry on certain attempts to allow a single server to recover. Is this the
> behavior you’re looking for?
>
> On a side-note, their doc referred to apache ldap api as ‘beta’ quality,
> i.e. not ready for production, which obviously is not right.
>
> If we decide to proceed with this idea, we’ll need to post on the
> developer’s list to get the api guys on board.
>
> Shawn
Re: Supporting LDAP HA client
Posted by Shawn McKinney <sm...@apache.org>.
> On Apr 15, 2018, at 11:19 PM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
>
> Do we have a plan to support ldap HA client?
>
> I think it is possible to extend
> "org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory" and
> make some connection strategy similar like
> http://www.ldaptive.org/docs/guide/connections.html.
>
> What do you guys think about this?
Hi Yudhi, read the page, are you referring to the section 'Operation Retry’?
Another question, what do you consider HA? I Remember the old netscape ldap api (as do others like python’s ldap3) allow the client to specify a server pool, which then enables the api to roundrobin, or some other protocol, to each server in attempt to find one that is active.
To me this server pool is ‘HA'. But reading the doc, it seems this ldapative api (first I heard of this one) uses an approach where it will retry on certain attempts to allow a single server to recover. Is this the behavior you’re looking for?
On a side-note, their doc referred to apache ldap api as ‘beta’ quality, i.e. not ready for production, which obviously is not right.
If we decide to proceed with this idea, we’ll need to post on the developer’s list to get the api guys on board.
Shawn