On 11.06.2010 20:06, LES wrote:
I only added socket_timeout in after looking at the included file in 1.2.30.
I was hoping that there was something in that file that I was missing.
I attached the log files that you asked for. Looking through them, I don't
see any notable increases in response times. This is a system that is not
(yet) actively used, so there is very little load. The thread dumps and the
gc log do not seem to indicate that tomcat is pausing in some meaningful
way. Also, during this time period, the http connectors in the tomcat
instances are responding without delay (hitting the manager page). Another
detail is that bouncing tomcat will clear up this problem for some unknown
period of time.
Here is the worker.properties file:
*******************************
...
************************
Any thoughts?
Thanx for the time,
LES
http://old.nabble.com/file/p28858465/modjk_log_files.tar.gz
modjk_log_files.tar.gz
You have a locking issue in your webapp. Look at the thread dump. the
threads used for processing of requests coming in via the AJP connector
are named TP-ProcessorN where N is some number.
There are 188 of them that hang in the stack:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:485)
com.tc.object.lockmanager.impl.ClientLock.waitForLock(ClientLock.java:688)
com.tc.object.lockmanager.impl.ClientLock.basicLock(ClientLock.java:242)
com.tc.object.lockmanager.impl.ClientLock.lock(ClientLock.java:133)
com.tc.object.lockmanager.impl.ClientLock.lock(ClientLock.java:120)
com.tc.object.lockmanager.impl.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:341)
com.tc.object.lockmanager.impl.StripedClientLockManagerImpl.lock(StripedClientLockManagerImpl.java:105)
com.tc.object.lockmanager.impl.ThreadLockManagerImpl.lock(ThreadLockManagerImpl.java:46)
com.tc.object.tx.ClientTransactionManagerImpl.begin(ClientTransactionManagerImpl.java:232)
com.tc.object.bytecode.ManagerImpl.begin(ManagerImpl.java:355)
com.tc.object.bytecode.ManagerImpl.beginLock(ManagerImpl.java:340)
com.tc.object.bytecode.ManagerUtil.beginLock(ManagerUtil.java:180)
com.tc.object.bytecode.ManagerUtil.beginLock(ManagerUtil.java:162)
com.terracotta.session.util.Lock.getWriteLock(Lock.java:36)
com.terracotta.session.util.DefaultSessionId.getWriteLock(DefaultSessionId.java:64)
com.terracotta.session.SessionDataStore.find(SessionDataStore.java:144)
com.terracotta.session.TerracottaSessionManager.getSessionIfExists(TerracottaSessionManager.java:426)
com.terracotta.session.SessionRequest.getTerracottaSession(SessionRequest.java:104)
com.terracotta.session.SessionRequest.getSession(SessionRequest.java:63)
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:206)
The locks they are waiting for are not the same, i.e. 188 different ones.
Another problem is 4 more threads also waiting for locks in the stack:
java.lang.Thread.sleep(Native Method)
com.beip.domain.integration.cognos.c8.exec.ConnectionManager.getConnection(ConnectionManager.java:132)
com.beip.domain.integration.cognos.c8.request.ConversationManager.validateReportPath(ConversationManager.java:80)
com.beip.domain.integration.cognos.c8.request.ConversationManager.createConversation(ConversationManager.java:43)
sun.reflect.GeneratedMethodAccessor11599.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:899)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:765)
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:753)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
com.beip.gap.framework.controller.C8Controller$_closure2.doCall(script1274905317445.groovy:63)
sun.reflect.GeneratedMethodAccessor11597.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:250)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
com.beip.gap.framework.controller.C8Controller$_closure2.doCall(script1274905317445.groovy)
sun.reflect.GeneratedMethodAccessor11596.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:250)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:740)
groovy.lang.Closure.call(Closure.java:292)
com.beip.web.groovy.GroovyControllerSupport.handleAction(GroovyControllerSupport.java:177)
com.beip.web.groovy.GroovyControllerSupport.handleRequest(GroovyControllerSupport.java:115)
Those requests hang and will not show up in any access log (they never
completed).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
