On 25/12/2011 02:17, Matthew Tyson wrote:

>> INFO  2011-12-24 10:25:35,578 COMET  REQUEST: 75.149.42.46  POST  null |
>> TRACE:
>> java.lang.Throwable
>>         at org.cometd.server.CometdServlet.service(CometdServlet.java:149)
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>>         at
>> com.company.util.filter.MonitoringFilter.doFilter(MonitoringFilter.java:47)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>>         at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
>>         at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
>>         at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
>>         at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
>>         at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
>>         at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
>>         at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>>         at
>> com.company.util.tomcat.SecureProxyValve.invoke(SecureProxyValve.java:57)
>>         at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>>         at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
>>         at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
>>         at
>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1571)
>>          at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>         at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>         at java.lang.Thread.run(Thread.java:662)

That all looks pretty normal. What I am wondering now, is what is
calling NioEndpoint.processSocket()

I'd suggest if at all possible, setting up your Tomcat instance to allow
remote debugging and then once the instance gets into this state check
what is calling that code. It gets called far too often to output a
stack trace every call during normal operation.

>>> 2. How comfortable are you patching Tomcat and building it from source?
>>> I have some debug logging sat in a git branch that I use for debugging
>>> similar issues that will generate a lot of logging but show exactly what
>>> is happening. I can either provide you with the patch or an updated JAR
>>> (or JARs) that you can drop into a 7.0.23 instance.
>>>
>> Does the stack trace shed any light?  If not, I can try the JAR or the git
>> branch.

I'm not sure my debug code is in the right place for this. If the
debugging above isn't possible then patching Tomcat may be the only
option. It sounds like you know enough of what you are doing to just
patch it if required (noting that any such patch will generate a lot of
output in normal running) but feel free to ask here if I have misjudged
things.


> I noticed in the stack trace our custom valve.  Its a very simple valve
> that just checks what port a request came in on and sets a flag on the
> request object:
> 
>  public void invoke(Request req, Response resp) throws IOException,
> ServletException {
> 
>         if (req.getLocalPort() == secureProxyPort) {
>             req.setSecure(true);
>             req.setServerPort(serverPort);
>         }
> 
>         if (getNext() != null) {
>             getNext().invoke(req, resp);
>         }
>     }
> 
> I disabled the valve, and so far, the repeating requests have stopped.  (I
> should mention that asyncSupported is true on this valve).
> 
> Any thoughts on why this would cause this problem?

Strange. I don't see anything wrong with that but if there is a
threading problem at the bottom of this, the timing change this creates
may be enough to trigger whatever the problem is.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to