> On Mar 22, 2016, at 8:30 AM, Chris Pike <[email protected]> wrote: > > Agree, not being able to easily reproduce is problematic... might look into a > way to simulate network latency and see if that helps reproduce.
The theory is the app server is hanging because the app being redeployed isn’t closing connections right? But it only happens once in a while, why is that? Looking at the stack trace once again: > > On Mar 21, 2016, at 11:18 AM, Chris Pike <[email protected]> wrote: > > 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) what clues does it offer? Going from bottom up we can see we’re in the middle of a fortress createSession call. This tells us that we’re redeploying while a thread is actively engaged in a conversation with the ldap server. Maybe you can simulate this scenario by connecting remotely to a wildfily instance with debugger, setting a breakpoint after the lock has been set (in the ldap api), and redeploying while halted on that step. Shawn
