2012/1/15 Mark Thomas <ma...@apache.org>: > On 15/01/2012 06:06, Konstantin Kolinko wrote: >> 2012/1/15 <build...@apache.org>: >>> The Buildbot has detected a new failure on builder tomcat-trunk while >>> building ASF Buildbot. >>> Full details are available at: >>> http://ci.apache.org/builders/tomcat-trunk/builds/2653 >>> >>> Buildbot URL: http://ci.apache.org/ >>> >>> Buildslave for this Build: bb-vm_ubuntu >>> >>> Build Reason: scheduler >>> Build Source Stamp: [branch tomcat/trunk] 1231625 >>> Blamelist: kkolinko >>> >>> BUILD FAILED: failed compile_1 >>> >> >> It is "org.apache.catalina.mbeans.TestRegistration FAILED" for BIO. >> The following mbean was printed to the log before the failure: >> [[[ >> [junit] Jan 15, 2012 5:27:13 AM >> org.apache.catalina.mbeans.TestRegistration testMBeanDeregistration >> [junit] INFO: Name: >> Tomcat:type=RequestProcessor,worker="http-bio-127.0.0.1-auto-1",name=HttpRequest1 >> [junit] modelerType: org.apache.tomcat.util.modeler.BaseModelMBean >> [junit] requestProcessingTime: 1326605233578 >> [junit] bytesSent: 0 >> [junit] rpName: >> Tomcat:type=RequestProcessor,worker="http-bio-127.0.0.1-auto-1",name=HttpRequest1 >> [junit] processingTime: 0 >> [junit] errorCount: 0 >> [junit] maxTime: 0 >> [junit] requestBytesReceived: 0 >> [junit] stage: 1 >> [junit] lastRequestProcessingTime: 0 >> [junit] globalProcessor: org.apache.coyote.RequestGroupInfo@58b51c29 >> [junit] serverPort: -1 >> [junit] bytesReceived: 0 >> [junit] requestCount: 0 >> [junit] requestBytesSent: 0 >> [junit] contentLength: -1 >> [junit] remoteAddr: 127.0.0.1 >> ]]] >> >> So, it has remoteAddr, but it looks like nothing was received. > > Could this be the call to unlock the acceptor? >
Yes! 1. JIoEndpoint$Acceptor does not check "running" and "paused" flags after accepting the socket and passes it for further processing 2. NioEndpoint$Acceptor checks the flags, but it seems that if "!running" or "paused" flags are set then it does not properly close the accepted socked thus losing it. 3. AprEndpoint$Acceptor seems better, but why it checks the flags only if "deferAccept" is true? Do we really need to start RequestProcessor and consume that OPTIONS request sent by AbstractEndpoint.unlockAccept() ? Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
