On 07/01/2012 15:49, Konstantin Kolinko wrote: > 2012/1/7 Mark Thomas <ma...@apache.org>: >> On 07/01/2012 03:57, Bill Barker wrote: >>> Gump Run 11000007012012, vmgump.apache.org:vmgump:11000007012012 >>> Gump E-mail Identifier (unique within run) #27. >>> >>> -- >>> Apache Gump >>> http://gump.apache.org/ [Instance: vmgump] >> >> This is odd. >> >> Here is an extract from the test log [1] (this will disappear with the >> next run). >> >> Testcase: testMBeanDeregistration took 1.673 sec >> FAILED >> Remaining: >> [Tomcat:type=RequestProcessor,worker="http-bio-auto-1",name=HttpRequest2, >> Tomcat:type=RequestProcessor,worker="http-bio-auto-1",name=HttpRequest1] >> expected:<0> but was:<2> >> junit.framework.AssertionFailedError: Remaining: >> [Tomcat:type=RequestProcessor,worker="http-bio-auto-1",name=HttpRequest2, >> Tomcat:type=RequestProcessor,worker="http-bio-auto-1",name=HttpRequest1] >> expected:<0> but was:<2> >> at >> org.apache.catalina.mbeans.TestRegistration.testMBeanDeregistration(TestRegistration.java:189) >> >> >> That says to me that Tomcat was processing incoming requests at the time >> which is unexpected as TestRegistration doesn't trigger any requests. >> >> I am very curious as to where these incoming requests came from. >> >> This looks to be a false positive to me but I do wonder what is going on >> with this test environment. I guess it may have been hit by a port scan >> or similar. I wonder if something similar is behind the Comet failures? >> >> Some random thoughts for ways forward: >> - limit test connectors to listen only on localhost > > +1 > >> - work with infra to configure the firewall on that vm > > If they are concerned that someone scans ports on their server... > > Re: Comet tests - you think these requests may interfere with timing? > (like polluting the network?)
Maybe keeping connections open, stopping the connector from shutting down fully or something. I'm not really sure. More a shot in the dark really. > They should not be able to interfere with connections that are already > established. The servlets in the tests have specific addresses (like > "/comet"), so it is unlikely that random requests would reach them. Agreed. But i think they could interfere with a clean shutdown. > The random ports numbers on Unixes are >32k, so it is unlikely that we > collided with some known port number. Agreed. > I like the idea of limiting connectors to listening on localhost. > > > 2012/1/7 Rainer Jung <rainer.j...@kippdata.de>: >> >> Maybe enable the accesslog during testing with test.accesslog=true, so one >> can check after the next failure whether the contents agree with your >> assumption. Not sure, whether Gump offers access to the access log for >> checking. > > +1, but needs some fixes in the tests that check their own access logs. > > IIRC they disable their own access logging and checks if that flag is > set. That is because some time ago Tomcat allowed only single > AccessLogValve per container. > > I implemented support for multiple AccessLogValves per container in > TC7 several releases ago, so it should be possible to remove that > logic from tests. It is somewhere on my TODO list. Maybe you'll get to it before I do :) > Access to access log file should be configurable in Gump. I have less > expectations for Buildbot (where we do not yet have access to JUnit > report files). > >> [1] >> http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_file/TEST-org.apache.catalina.mbeans.TestRegistration.BIO.txt.html Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
