Sahoo,
That was considered. It was an ORB change.
I am sorry but you do not have the whole test picture here, take it
offline with me if you'd lie.
Lloyd
On Sep 8, 2009, at 9:27 AM, Sahoo wrote:
> Lloyd Chambers wrote:
>> I have two other points I'll make here:
>>
>> 1) The real failure is not running QL before integrating. That's a
>> process problem. Such things happen, that's life.
>>
>> 2) "The solution to failing tests is to remove the tests". An
>> interesting idea that carries other risks.
> No, the solution should have been to undo the changes that caused
> the regression. If that's not done because the change is more
> important than than the feature that's broken, then file a bug and
> temporarily don't run the test that fails. That way we don't waste
> each others' time.
>
> Sahoo
>>
>> Abhijit should make the call on disabling the tests, but I'd prefer
>> he establishes a written policy as part of our process guidelines.
>> It's not my call, it's his, I stand ready to do whatever he decides.
>>
>> I'm not looking for more discussion here, I'm satisfied with
>> whatever Abhijit wants to do.
>>
>> Lloyd
>>
>> On Sep 8, 2009, at 8:53 AM, Lloyd Chambers wrote:
>>
>>> There is hardly unanimous agreement here.
>>>
>>> How much time is wasted? Seems like a false assumption. Is this
>>> failure so hard to understand?
>>>
>>> testAMXComplianceMonitorFailureCount___KNOWN_FAILURE_20090904_ISSUE_9355_IGNORE_FOR_NOW
>>>
>>> So when the test is disabled, *more* bugs can go in undetected?
>>> There is a larger picture to be understood.
>>>
>>> =====> Abhijit should make the call.
>>>
>>> Lloyd
>>>
>>> On Sep 4, 2009, at 9:48 PM, Sahoo wrote:
>>>
>>>> I agree with Kedar. Look the amount of time wasted because of a
>>>> known failure. We can keep a bug open to ensure that the test is
>>>> re-enabled.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Kedar Mhaswade wrote:
>>>>> I was suggesting a temporary disablement so others can continue
>>>>> with
>>>>> their chores. It's lame too to expect a known failure to show up.
>>>>> So, I vote for (temporarily) disabling it.
>>>>>
>>>>> 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.
>>>>>
>>>>> But still, I won't know if the failure is because of the fact that
>>>>> there is a known cause for it or because my changes are (also)
>>>>> causing
>>>>> it.
>>>>>
>>>>>>
>>>>>> I have NOT seen amxtest.AMXCoreTests.iterateAllSanityCheck()
>>>>>> fail, so that one needs looking into.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> 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