It's probably a timing thing due to the other failures. The server
log probably yields an indication of what, exactly.
On Sep 4, 2009, at 3:22 PM, Richard S. Hall wrote:
> I ran again and didn't get the iterateAllSanityCheck() failure this
> time, so I am not sure if that is a good thing or not...perhaps it
> is intermittent.
>
> -> richard
>
> On 9/4/09 18:10, Richard S. Hall wrote:
>>
>> On 9/4/09 17:16, Lloyd Chambers wrote:
>>>
>>> Abhijit is trending strongly towards disabling the test for this
>>> reason (confusion).
>>>
>>> They indicate real problem with the ORB MBeans, but not problems
>>> that affect the overall server operation.
>>>
>>> So what it comes down to is what our policy in removing tests that
>>> detect real problems? I think it's kinda lame to have tests, then
>>> turn them off when real problems crop up.
>>>
>>> My other suggestion was to have the test itself emit a message
>>> indicating that it is a known issue.
>>>
>>> I have NOT seen amxtest.AMXCoreTests.iterateAllSanityCheck() fail,
>>> so that one needs looking into.
>>
>> Ok, so the other one is known, but this one is not. Hmm. I guess I
>> will look into it. :-(
>>
>> Here is the stack trace:
>>
>> java.lang.NullPointerException
>> at amxtest.AMXCoreTests.iterateAllSanityCheck(AMXCoreTests.java:94)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke
>> (NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>> (DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:
>> 604)
>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:470)
>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564)
>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830)
>> at org.testng.internal.TestMethodWorker.invokeTestMethods
>> (TestMethodWorker.java:125)
>> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:
>> 109)
>> at org.testng.TestRunner.runWorkers(TestRunner.java:678)
>> at org.testng.TestRunner.privateRun(TestRunner.java:624)
>> at org.testng.TestRunner.run(TestRunner.java:495)
>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:300)
>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295)
>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275)
>> at org.testng.SuiteRunner.run(SuiteRunner.java:190)
>> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792)
>> at org.testng.TestNG.runSuitesLocally(TestNG.java:765)
>> at org.testng.TestNG.run(TestNG.java:699)
>> at org.testng.TestNG.privateMain(TestNG.java:824)
>> at org.testng.TestNG.main(TestNG.java:802)
>>
>>
>> -> richard
>>
>>>
>>> Lloyd
>>>
>>> On Sep 4, 2009, at 1:54 PM, Kedar Mhaswade wrote:
>>>
>>>> I get the failure with:
>>>> amxtest.AMXCoreTests:testAMXComplianceMonitorFailureCount
>>>>
>>>> It's not clear if that's the same as the one reported in 9355.
>>>>
>>>> BTW, can we temporarily disable the test so that we get a clean
>>>> run every time? When the bug is fixed, we can re-enable it.
>>>>
>>>> Thanks.
>>>>
>>>> Jane Young wrote:
>>>>> I know #2 is a known issue. See IT 9355
>>>>> and
>>>>> http://gf-hudson.sfbay.sun.com/hudson/job/gf-trunk-build-continuous/2205/artifact/bundles/QL-GP-report.html
>>>>> I'm not sure about #1. Are you getting total of 2 failures or 1?
>>>>
>>>>> Richard S. Hall wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am trying to make sure that Felix 2.0 is ready for release.
>>>>>> My latest run comes up with the following QL failures:
>>>>>>
>>>>>> 1. iterateAllSanityCheck
>>>>>> java.lang.NullPointerException
>>>>>> at amxtest.AMXCoreTests.iterateAllSanityCheck
>>>>>> (AMXCoreTests.java:94)
>>>>>> 2. testAMXComplianceMonitorFailureCount
>>>>>> java.lang.AssertionError: Server indicates that there are
>>>>>> non-compliant AMX MBean validator failures, failure count = 20,
>>>>>> examine the server log for failures
>>>>>> at
>>>>>> amxtest.AMXCoreTests.testAMXComplianceMonitorFailureCount
>>>>>> (AMXCoreTests.java:112)
>>>>>>
>>>>>> Are these normal failures in GF trunk?
>>>>>>
>>>>>> -> richard
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> Lloyd Chambers
>>> lloyd.chambers_at_sun.com
>>> GlassFish Team
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team