Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of rainer.jung@kippdata.de
 designates 195.227.30.149 as permitted sender)
Message-ID: <4F0C5931.6020100@kippdata.de>
Date: Tue, 10 Jan 2012 16:28:49 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: dev@tomcat.apache.org
Subject: Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk)
 failed
References: 
 <20120107035710.79F0D149EA3@vmgump.apache.org><4F080BEB.7070900@apache.org><CABzHfVn8X6rTzKyn1aC6NSgQc1A7KkaDb7dqgTeWutBYa7XmSg@mail.gmail.com><4F087928.2020709@apache.org><CABzHfV=ABq7s1rZ_OPfSAewv9gj3kGGO6G3XvjNoMFbpESJXww@mail.gmail.com><CABzHfVmT8QSTC3_47_YUYoJZpoJmS4QryQK1cd=kYmfE8zzBkA@mail.gmail.com><CABzHfVnTz+DMXpgS_SVdQ1DPAtFRL_9+-yVS+eZz9XxBDU-KjQ@mail.gmail.com><4F0C1169.9040908@kippdata.de>
 <CABzHfVnBZ0sEh29EPHgVcdERi5vzA5vf94c-SvRe6Hgmfks5iA@mail.gmail.com>
In-Reply-To: 
 <CABzHfVnBZ0sEh29EPHgVcdERi5vzA5vf94c-SvRe6Hgmfks5iA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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