james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: Notes on JAMES-1352 Commits
Date Mon, 19 Dec 2011 18:48:26 GMT
Hi Steve,

I finally found time to look at the code and can now better realize what 
you did :)

Just giving you some loosely feedback I noted:

- What's the difference between perform() and operation() methods? I'm 
not sure to completely get it from javadoc :) - reading 
RetryingLdapContext gives me more info, but
- ExceptionRetryingProxy could eventually be called 
ExceptionRetryingDelegate (deals with newDelegate()... and a proxy 
sounds more like implementing the same api as the proxied object)
- Could the api reside in lifecyle-api (or data-api?) and the 
implementation be moved to ldap module (does it make sense?)
- All methods of Dir/LdapContext need to be reimplemented with the 
operation()/perform(). The good side I see is that the retry will always 
work, the downside is that it demands much code writing.
CommunicationException.class+ServiceUnavailableException.class, and not 
simply NamingException.class?
- Small details: the other James classes don't use _field nomenclature 
(just field without underscore)

One more question: Is this common practice to have to recreate a new 
InitialLdapContext this way, or does it exist some kind of 
LdapConnectionPool that would handle this for us?

Thx again,


On 18/12/11 19:33, Steve Brewin wrote:
> Hi Eric
> A brief break between other duties, so here's a partial reply...
> While looking at the code you will see that one of the interfaces
> introduced in Util is RetrySchedule. The default implementation is
> DoublingRetrySchedule which, as the JavaDocs explain, doubles the retry
> rest period after each failed attempt up to a set limit.
> This algorithm usually works well in the overload scenarios you
> describe. If it doesn't, in my experience, the next algorithm to try is
> one that randomizes the rest period within certain limits so that
> retries from different sources don't coincide because they are following
> the same algorithm in lock step.
> Using an interface allows the algorithm to be changed. Placing this and
> their implementations in Util allows other things to use them. For
> instance, RemoteDelivery could do with some reworking should someone
> feel up to the task :)
> Cheers
> --Steve
> On 18/12/2011 18:02, Steve Brewin wrote:
>> Hi Eric
>> It's probably better that you look at the code first and ask questions
>> later. It will be quicker this way :)
>> Cheers
>> --Steve
>> On 18/12/2011 18:19, Eric Charles wrote:
>>> Hi Steve,
>>> Last time I connected to LDAP from JAVA code is ten years ago.
>>> I don't remember if we were using a connection pool or whatever...
>>> A timeout can occur on an overloaded LDAP server, and retrying gives
>>> a risk to make things worst as the LDAP will keep on to be more and
>>> more overloaded due to retrying clients.
>>> I will take some time in coming days to look at the Tomcat's JNDI
>>> Realm as well as to your code (and see if you retry with incremental
>>> period of time for example).
>>> Can you also further elaborate on your Q2 (the interfaces in util)?
>>> Thx again,
>>> Eric
>>> On 18/12/11 12:38, Steve Brewin wrote:
>>>> Hi Eric
>>>> Even when deployed in highly resilient infrastructures with multiple
>>>> LDAP servers there is a need to retry in the case where the server
>>>> connected to fails. In this scenario, a single instantaneous retry is
>>>> sufficient.
>>>> In less resilient infrastructures, retry provides a greater level of
>>>> resilience. Retrying over a defined duration offers an alternative to
>>>> having to recycle James should the LDAP server become temporarily
>>>> unavailable.
>>>> The former is common, see Tomcat's JNDI Realm. The latter easy to
>>>> provide once support for the former is added. So why not?
>>>> Cheers
>>>> --Steve
>>>> On 18/12/2011 11:09, Eric Charles wrote:
>>>>> Hi Steve,
>>>>> I will take more time in the next days to comment on:
>>>>> - Why do we need some retry (I know you asked the question before and
>>>>> I didn't answer by lack of time - just curious to further discuss,
>>>>> won't ask for any revert :).
>>>>> - I saw util maven project more for utility classes, without any
>>>>> further structure.
>>>>> Stay tuned.
>>>>> Thx,
>>>>> Eric
>>>>> On 13/12/11 12:09, Steve Brewin wrote:
>>>>>> Hi
>>>>>> Yesterday I committed fixes for JAMES-1352 "Increase the
>>>>>> robustness of
>>>>>> org.apache.james.userldap.ReadOnlyUsersLDAPRepository". A few design
>>>>>> questions arise from this.
>>>>>> Aside from a little house-keeping, the only changes to the
>>>>>> org.apache.james.userldap package are:
>>>>>> - The introduction of a retryable LDAP context via a proxy class.
>>>>>> - Authorization uses a reconnect() on a new instance of the existing
>>>>>> LdapContext, thereby propagating all other Context related settings.
>>>>>> - All retry functionality is implemented in
>>>>>> org.apache.james.util.retry.* packages as this retry functionality
>>>>>> generic and reusable. In fact, there are no references to other James
>>>>>> packages here.
>>>>>> Q1: Are there any objections to factoring the generic behaviour into
>>>>>> org.apache.james.util. as done here? If so, we can repackage.
>>>>>> Where else
>>>>>> should it live?
>>>>>> Q2: I've introduced interfaces into the maven james-server-util
>>>>>> project.
>>>>>> Some, but not all, other projects have been split to separate classes
>>>>>> from interfaces. Do we need to do this here? Or should we wait
>>>>>> until the
>>>>>> interfaces are actually used outside of the james-server-util
>>>>>> project?
>>>>>> Cheers
>>>>>> Steve
>>>>>> - - - - - - - - - - - - - - - - - -
>>>>>> This private and confidential e-mail has been sent to you by Synergy
>>>>>> Systems Limited. It may not represent the views of Synergy Systems
>>>>>> Limited.
>>>>>> If you are not the intended recipient of this e-mail and have
>>>>>> received
>>>>>> it in error, please notify the sender by replying with "received
>>>>>> error" as the subject and then delete it from your mailbox.
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

Eric http://about.echarles.net

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message