tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
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 <markt@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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message