Anil,
Thanks for the explanation. My config is listed below. It was taken from
the
sample security.xml. I did not add or substract, only modified the value
of
LDAP configuration.
Well, I guess the problem with Directory Services is that the ldap server
is
used by the entire enterprise and they don't want anybody to maintain a
connection pool (probably not even one). If one connection for each app,
that can amount to thousands of idle connections for them. So they would
like every app to disconnect once the lookup is done. This may not make
sense from app's point of view, but make sense from ldap server!
So if I can set java -DDcom.sun.jndi.ldap.connect.pool.timeout=100 during
startup of Roller, I can override the timout setting of Acegi? I will give
it a shot later to see if it works for me...
Steve Lihn
<!-- Sample LDAP/RollerDB hybrid security configuration -->
<bean id="initialDirContextFactory"
class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
<constructor-arg
value="ldaps://dsdvm01:636/ou=People,dc=iM-2,dc=com"/>
<property
name="managerDn"><value>cn=mrkwiki,ou=Applications,ou=Merck,ou=Services,dc=i
M-2,dc=com</value></property>
<property name="managerPassword"><value>xxx</value></property>
<property name="extraEnvVars">
<map>
<entry>
<key>
<value>java.naming.referral</value>
</key>
<value>follow</value>
</entry>
</map>
</property>
</bean>
<bean id="ldapUserSearch"
class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg index="0">
<value></value>
</constructor-arg>
<constructor-arg index="1">
<value>(uid={0})</value>
</constructor-arg>
<constructor-arg index="2">
<ref local="initialDirContextFactory" />
</constructor-arg>
<property name="searchSubtree">
<value>true</value>
</property>
</bean>
<bean id="ldapAuthProvider"
class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
<constructor-arg>
<bean
class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
<constructor-arg><ref
local="initialDirContextFactory"/></constructor-arg>
<property name="userSearch"><ref
bean="ldapUserSearch"/></property>
</bean>
</constructor-arg>
<constructor-arg><ref
local="jdbcAuthoritiesPopulator"/></constructor-arg>
<property name="userCache" ref="userCache"/>
</bean>
<bean id="jdbcAuthoritiesPopulator"
class="org.apache.roller.ui.core.security.AuthoritiesPopulator">
<property name="dataSource">
<bean class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"
value="java:comp/env/jdbc/rollerdb"/>
</bean>
</property>
<property name="authoritiesByUsernameQuery">
<value>SELECT username,rolename FROM userrole WHERE username =
?</value>
</property>
<property name="defaultRole"><value>register</value></property>
</bean>
<!-- end of LDAP section -->
-----Original Message-----
From: Anil Gangolli [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 2:09 AM
To: [email protected]
Subject: Re: LDAP connection lasts for 2 minutes
What does your config look like?
And what exactly is the problematic behavior?
If you're seeing a lot of such connections and not with a lot of
simultaneous logins going on, it may be an issue with the integration or
your setup.
If it is one connection being held by Roller to the LDAP server, I'm not
sure what the beef is about.
Regarding your question about options for controlling the configuration
around this, I think Spring's default directory context factory uses an
underlying Sun implementation com.sun.jndi.ldap.LdapCtxFactory and I think
Spring enables the pooling option on this factory by default. I'd enable
it
explicitly if it is not.
Parameters controlling the pool, including the idle timeout, are described
here:
http://java.sun.com/products/jndi/tutorial/ldap/connect/config.html
They are JVM-wide system properties.
Hope this helps. More info from your side might yield a better diagnosis.
--a.
----- Original Message -----
From: "Lihn, Steve" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 22, 2006 7:47 AM
Subject: LDAP connection lasts for 2 minutes
Hi,
Anybody has any idea to this LDAP issue?
Acegi developers did not reply...
Thanks,
Steve Lihn
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of
Lihn, Steve
Sent: Wednesday, September 20, 2006 12:00 PM
To: '[email protected]'
Subject: [Acegisecurity-developer] LDAP connection lasts for 2 minutes
Hi,
We are using Acegi's LDAP auth provide for Roller 3.0. The Directory
Services department contacted me yesterday explaining Acegi made
connection
to LDAP, but not releasing it for about 2 minutes. They said, the binding
of
the user DN was released immediately, but the application id (manager DN)
binding is hanging for too long. They questioned why it can not be
released
immediately?
Is there a timeout parameter I can set in Acegi for this problem?
Steve Lihn
----------------------------------------------------------------------------
--
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
----------------------------------------------------------------------------
--
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
------------------------------------------------------------------------------
