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?) 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. The random ports numbers on Unixes are >32k, so it is unlikely that we collided with some known port number. 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. 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 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
