This problem reared it's ugly head again... fortunately, we were able to get a
thread dump and it looks like it is an issue with the ldap api connection code
blocking while waiting for a response it will never receive. This happens when
undeploying the service from our application server. Any ideas on why this is
happening?
"default task-26" #589 prio=5 os_prio=0 tid=0x00007f7bee442800 nid=0x23a3
waiting on condition [0x00007f7bb9f57000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000005235617a0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
at
org.apache.directory.ldap.client.api.future.ResponseFuture.get(ResponseFuture.java:130)
at
org.apache.directory.ldap.client.api.future.SearchFuture.get(SearchFuture.java:69)
at
org.apache.directory.ldap.client.api.SearchCursorImpl.next(SearchCursorImpl.java:119)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection.lookup(LdapNetworkConnection.java:3422)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection.lookup(LdapNetworkConnection.java:3393)
at
org.apache.directory.ldap.client.api.LdapConnectionWrapper.lookup(LdapConnectionWrapper.java:483)
at
org.apache.directory.ldap.client.api.LookupLdapConnectionValidator.validate(LookupLdapConnectionValidator.java:49)
at
org.apache.directory.ldap.client.api.AbstractPoolableLdapConnectionFactory.validateObject(AbstractPoolableLdapConnectionFactory.java:173)
at
org.apache.directory.ldap.client.api.AbstractPoolableLdapConnectionFactory.validateObject(AbstractPoolableLdapConnectionFactory.java:38)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1205)
at
org.apache.directory.ldap.client.api.LdapConnectionPool.getConnection(LdapConnectionPool.java:123)
at
org.apache.directory.fortress.core.ldap.ApacheDsDataProvider.getAdminConnection(ApacheDsDataProvider.java:1455)
at org.apache.directory.fortress.core.impl.UserDAO.getUser(UserDAO.java:829)
at org.apache.directory.fortress.core.impl.UserP.read(UserP.java:216)
at
org.apache.directory.fortress.core.impl.UserP.createSessionTrusted(UserP.java:522)
at
org.apache.directory.fortress.core.impl.UserP.createSession(UserP.java:454)
at
org.apache.directory.fortress.core.impl.AccessMgrImpl.createSession(AccessMgrImpl.java:118)
at
edu.psu.swe.fortress.producer.FortressManagerProducer.getUserSession(FortressManagerProducer.java:114)
at
edu.psu.swe.fortress.producer.FortressManagerProducer.createAccessManager(FortressManagerProducer.java:94)
at sun.reflect.GeneratedMethodAccessor911.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
----- Original Message -----
From: "Chris Pike" <[email protected]>
To: [email protected]
Sent: Friday, March 11, 2016 12:19:21 PM
Subject: Re: LDAP Connection Management
Sure, after looking at it some more, the cache values are being updated, so I'm
going to test if we can just use the cache APIs locking methods.
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
Sent: Friday, March 11, 2016 11:19:28 AM
Subject: Re: LDAP Connection Management
> On Mar 11, 2016, at 10:11 AM, Chris Pike <[email protected]> wrote:
>
> Found another place wehre this might be an issue...
>
> OrgUnitP and PolicyP both use read locks in the isValid method and write
> locks in the add method, but only around getting user and policy sets
> respectively. Also, it looks like PolicyP calls lock on read lock method
> multiple times (isValid and getPolicySet).
>
> Since these are both also using a blocking cache, I think the locking is
> unnecessary.
Makes sense that we would fix these all now. Chris can you make the change to
code?
Shawn
