tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
Date Sat, 07 Jan 2012 16:56:08 GMT
On 07/01/2012 15:49, Konstantin Kolinko wrote:
> 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
> +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

> 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.


> 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.

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]


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

View raw message