Richard,
I think that 2nd failure is a side-effect of the first one somehow.
The Set is null, indicating some kind of inability to find AMX MBeans.
I'm 99% certain you can ignore it for your purposes.
@Test(dependsOnMethods = "bootAMX")
public void iterateAllSanityCheck()
{
final TimingDelta timing = new TimingDelta();
final TimingDelta overall = new TimingDelta();
final Set<AMXProxy> all = getAllAMX(); <=================
set is null, indicating severe failure
assert all.size() > 20;
//debug( "BasicAMXTests: millis to get queryAllSet(): " +
timing.elapsedMillis() );
for (final AMXProxy amx : all)
{
final Set<AMXProxy> children = amx.childrenSet();
if ( children.size() != 0 )
{
}
}
}
On Sep 4, 2009, at 3:10 PM, 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