tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
Date Sat, 07 Jan 2012 15:31:59 GMT
On 07.01.2012 10:10, Mark Thomas wrote:
> 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
> - work with infra to configure the firewall on that vm
>
> Thoughts?
>
> Mark
>
>
> [1]
> http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_file/TEST-org.apache.catalina.mbeans.TestRegistration.BIO.txt.html

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.

Regards,

Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message