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 Tue, 10 Jan 2012 15:28:49 GMT
On 10.01.2012 11:57, Konstantin Kolinko wrote:
> 2012/1/10 Rainer Jung<rainer.jung@kippdata.de>:
>> On 10.01.2012 05:27, Konstantin Kolinko wrote:
>>>
>>> 2012/1/10 Konstantin Kolinko<knst.kolinko@gmail.com>:
>>>>
>>>> 2012/1/9 Konstantin Kolinko<knst.kolinko@gmail.com>:
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>
>>>>> I updated Gump configuration for tc7 and trunk enabling the access
>>>>> log. We will see how it goes with next run.
>>>>>
>>>>
>>>> So Gump runs with access logs. Look for "access_log.yyyy-mm-dd" in the
>>>> list of files.
>>>>
>>>> (...)
>>>
>>>
>>> Last run of tomcat-tc7.0.x-test failed with
>>> org.apache.catalina.mbeans.TestRegistration.BIO.txt:
>>> [[[
>>> Testcase: testMBeanDeregistration took 1.756 sec
>>>         FAILED
>>> Remaining:
>>> [Tomcat:type=RequestProcessor,worker="http-bio-127.0.0.1-auto-1",name=HttpRequest1]
>>> expected:<0>    but was:<1>
>>> junit.framework.AssertionFailedError: Remaining:
>>>
>>> [Tomcat:type=RequestProcessor,worker="http-bio-127.0.0.1-auto-1",name=HttpRequest1]
>>> expected:<0>    but was:<1>
>>>         at
>>> org.apache.catalina.mbeans.TestRegistration.testMBeanDeregistration(TestRegistration.java:209)
>>> ]]]
>>
>>
>> I let the TC 7 tests run in a loop now locally, with a subset of the tests
>> (o.a.c.comet, ..., o.a.c.startup) and try to reproduce, no luck yet.
>>
>> I added a local patch, which logs the MBean attributes, if any unexpected
>> MBeans are found. That would only give some indication for the above case,
>> if the request was still being processed. I took the code (about 150 lines)
>> mostly unchanged from the JMXProxySerlvet. If you want I could apply to
>> TestRegistration.java in trunk.
>
> Yes, I think that is worth adding.

Done, I factored out a common dump class for MBeans, that's now used by 
JMXProxyServlet and TestRegistration. Format is the same, that 
JMXProxyServlet produced (code mostly unchanged).

> 2. The testMBeanDeregistration() method starts with
>
>          Set<ObjectName>  onames = mbeanServer.queryNames(new
> ObjectName("Catalina:*"), null);
>          assertEquals("Remaining: " + onames, 0, onames.size());
>
> I think the same check could be done with "Tomcat:*" names.

Added.

> The "TestRegistration.java:209" line where the assert was triggered is
> near the end of testMBeanDeregistration() method, so all of the method
> before that line did run fine.
>
> (From reading the code I think that the checks in the middle of
> testMBeanDeregistration() method would have detected unexpected beans
> if those were present before the test and logged them, but adding
> explicit check should not hurt.)

Agreed.

One observation, unrelated to the failure we were discussion above: if I 
dump all MBeans out of curiousity in the middle of TestRegistration, 
then I get a reproducible failure at the end:

     [junit] 10-Jan-2012 15:44:24.286 INFO [main] 
org.apache.catalina.mbeans.TestRegistration.testMBeanDeregistration
     [junit] 10-Jan-2012 15:44:24.290 INFO [main] 
org.apache.catalina.mbeans.TestRegistration.testMBeanDeregistration 
Name: Tomcat:type=Realm,realmPath=/realm0
     [junit] modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
     [junit] appName: Tomcat
     [junit] realmPath: /realm0
     [junit] stateName: STOPPED
     [junit] allRolesMode: strict
     [junit] className: org.apache.catalina.realm.JAASRealm
     [junit] useContextClassLoader: true
     [junit] validate: true

It seems the MBean for that Realm is created somehow when I query the 
other MBeans and retrieve their arguments, although the JAASRealm itself 
logs

   JAASRealm.setContainer Set JAAS app name Tomcat

much earlier.

If I dump all MBeans twice, then in the second dump the Realm MBean is 
contained (not in the first dump):

Name: Tomcat:type=Realm,realmPath=/realm0
modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
appName: Tomcat
realmPath: /realm0
stateName: STARTED
allRolesMode: strict
className: org.apache.catalina.realm.JAASRealm
useContextClassLoader: true
validate: true

But it seems it is never deresitered/destroyed during the test.

Thought you might be interested because of the "Re: problem using 
default Realm in new unit tests" discussion going on in parallel.

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