On 10.01.2012 11:57, Konstantin Kolinko wrote:
2012/1/10 Rainer Jung<rainer.j...@kippdata.de>:
On 10.01.2012 05:27, Konstantin Kolinko wrote:
2012/1/10 Konstantin Kolinko<knst.koli...@gmail.com>:
2012/1/9 Konstantin Kolinko<knst.koli...@gmail.com>:
2012/1/7 Rainer Jung<rainer.j...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
