tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
Date Sat, 07 Jan 2012 15:49:35 GMT
2012/1/7 Mark Thomas <>:
> On 07/01/2012 03:57, Bill Barker wrote:
>> Gump Run 11000007012012,
>> Gump E-mail Identifier (unique within run) #27.
>> --
>> Apache Gump
>> [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(
> 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


> - 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 <>:
> 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]

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message