james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Brewin <sbre...@synsys.com>
Subject Re: Notes on JAMES-1352 Commits
Date Sun, 18 Dec 2011 18:33:55 GMT
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 :)


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 is
>>>>> 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 in
>>>>> 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

View raw message