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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
--
Eric http://about.echarles.net
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
