Vladimir Ivanov wrote:
> On 12/20/06, Geir Magnusson Jr. wrote:
>>
>>
>>
>> Mikhail Loenko wrote:
>> > Instead we may remove all swing tests from CC when run on J9 and try to
>> > fix the
>> > problem
>>
>> +1
>>
>> geir
>
>
>
> To remove tests from CC only we need a special exclude lists for CC. Is it
> OK to store it together with modules exclude lists to update it with
> classlib ws?
I guess my question is "why is CC special?" IOW, shouldn't we exclude
those tests for J9 in general?
>
>
>
> Also option in the build to exclude some modules will be very useful.
> Something like '-Dnot.build.module=swing'.
>
>
>
> Thanks, Vladimir
>
>
>
>> >
>> > Thanks,
>> > Mikhail
>> >
>> >
>> > 2006/12/20, Vladimir Ivanov :
>> >> Actually, I was able to see these failures on swing tests only. But
>> >> even for
>> >> swing these failures reproduced intermittently and only when all swing
>> >> tests
>> >> run in the one VM.
>> >>
>> >>
>> >>
>> >> Thanks, Vladimir
>> >>
>> >>
>> >> On 12/19/06, Mikhail Loenko wrote:
>> >> >
>> >> > have you seen this stack when other tests run? maybe gui
>> >> > breaks something causing the failure? Are you able to reproduce the
>> >> > problem?
>> >> >
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >> > 2006/12/19, Vladimir Ivanov :
>> >> > > On 12/19/06, Ivanov, Alexey A < alexey.a.ivanov@intel.com> wrote:
>> >> > >
>> >> > > >
>> >> > > > There's only one GUI test in your list:
>> >> javax.swing.JToggleButtonTest.
>> >> > > > The others test text model, and this particular tests don't use
>> any
>> >> > > > swing UI components at all.
>> >> > > >
>> >> > > > If I remember your reports correctly, the latter three tests
>> fail
>> >> > > > because of some serialization failure.
>> >> > >
>> >> > >
>> >> > >
>> >> > > Yes, testParamString at javax.swing.JToggleButtonTest and
>> >> > testSerializable
>> >> > > for other tests. But actually the stack trace is similar
>> (below) so
>> I
>> >> > think
>> >> > > it not gui test problem. It is just reproduce this issue.
>> >> > >
>> >> > > Thanks, Vladimir
>> >> > > Stack trace:
>> >> > > Test: testParamStringClass: javax.swing.JToggleButtonTest
>> >> > > java.lang.ArrayIndexOutOfBoundsException
>> >> > > at java.util.Arrays.mergeSort(Arrays.java:2553)
>> >> > > at java.util.Arrays.mergeSort (Arrays.java:2516)
>> >> > > at java.util.Arrays.sort(Arrays.java:2872)
>> >> > > at java.util.Arrays.sort(Arrays.java:2889)
>> >> > > at java.beans.BeanInfoWrapper.getPropertyDescriptors(
>> >> > BeanInfoWrapper.java
>> >> > > :77)
>> >> > > at java.beans.BeanInfoWrapper.getPropertyDescriptors(
>> >> > BeanInfoWrapper.java
>> >> > > :74)
>> >> > > at javax.swing.JComponent.paramString(JComponent.java:1334)
>> >> > > at java.awt.Component.toString(Component.java:166)
>> >> > > at
>> >> javax.swing.JToggleButtonTest.testParamString(JToggleButtonTest.java
>> >> > :64)
>> >> > > at
>> >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
>> >> > > at
>> >> javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java
>> :117)
>> >> > > at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45)
>> >> > > at
>> >> java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92)
>> >> > > at
>> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:81)
>> >> > > at java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java
>> :133)
>> >> > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:144)
>> >> > > at
>> >> java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
>> >> > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
>> >> > >
>> >> > > Test: testSerializableClass:
>> >> > > javax.swing.text.AbstractDocument_SerializationTest
>> >> > > java.lang.ArrayIndexOutOfBoundsException
>> >> > > at java.util.Arrays.mergeSort(Arrays.java:2553)
>> >> > > at java.util.Arrays.mergeSort(Arrays.java:2516)
>> >> > > at java.util.Arrays.mergeSort(Arrays.java:2517)
>> >> > > at java.util.Arrays.sort(Arrays.java:2872)
>> >> > > at java.util.Arrays.sort(Arrays.java:2889)
>> >> > > at java.io.ObjectStreamClass.computeSerialVersionUID(
>> >> > ObjectStreamClass.java
>> >> > > :54)
>> >> > > at
>> java.io.ObjectStreamClass.addToCache(ObjectStreamClass.java:211)
>> >> > > at java.io.ObjectStreamClass.lookupStreamClass(
>> ObjectStreamClass.java
>> >> > :937)
>> >> > > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:90)
>> >> > > at java.io.ObjectStreamClass.addToCache(ObjectStreamClass.java
>> :23)
>> >> > > at java.io.ObjectStreamClass.lookupStreamClass(
>> ObjectStreamClass.java
>> >> > :937)
>> >> > > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:90)
>> >> > > at java.io.ObjectOutputStream.writeClassDescForClass(
>> >> > ObjectOutputStream.java
>> >> > > :110)
>> >> > > at java.io.ObjectOutputStream.writeNewObject(
>> ObjectOutputStream.java
>> >> > :1644)
>> >> > > at java.io.ObjectOutputStream.writeObjectInternal(
>> >> > ObjectOutputStream.java
>> >> > > :1956)
>> >> > > at java.io.ObjectOutputStream.writeObject
>> >> (ObjectOutputStream.java:1785)
>> >> > > at
>> >> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1749)
>> >> > > at javax.swing.BasicSwingTestCase.serializeObject(
>> >> > BasicSwingTestCase.java
>> >> > > :496)
>> >> > > at javax.swing.SerializableTestCase.setUp
>> >> (SerializableTestCase.java:50)
>> >> > > at javax.swing.text.AbstractDocument_SerializationTest.setUp
>> >> > > (AbstractDocument_SerializationTest.java:43)
>> >> > >
>> >> > >
>> >> > > > Regards,
>> >> > > > Alexey.
>> >> > > >
>> >> > > > >
>> >> > > > >
>> >> > > > >On 12/18/06, Geir Magnusson Jr. wrote:
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >> Mikhail Loenko wrote:
>> >> > > > >> > 2006/12/18, Geir Magnusson Jr. :
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > > > >> >> Mikhail Loenko wrote:
>> >> > > > >> >> > 2006/12/1, Geir Magnusson Jr. :
>> >> > > > >> >> >>
>> >> > > > >> >> >>
>> >> > > > >> >> >> Mikhail Loenko wrote:
>> >> > > > >> >> >> > 4) We have cruise controls running classlibrary tests
>> on
>> >> > > > DRLVM.
>> >> > > > >We
>> >> > > > >> >> >> > need to decide what will we do when DRLVM+Classlib
>> >> cruise
>> >> > > > control
>> >> > > > >> >> >> > reports failure.
>> >> > > > >> >> >>
>> >> > > > >> >> >> Stop and fix the problem. Is there really a question
>> >> > here? I
>> >> > > > >agree
>> >> > > > >> >> >
>> >> > > > >> >> > Yes, there is a question here. "Stop and fix" includes
>> >> > > > "discuss".
>> >> > > > >But
>> >> > > > >>
>> >> > > > >> >> > as we now know discussion may take several days. And
>> while
>> >> > some
>> >> > > > >> people
>> >> > > > >> >> > discuss what the problem is other people can't proceed
>> with
>> >> > > > >> >> > development and patch
>> >> > > > >> >> > intagration.
>> >> > > > >> >> >
>> >> > > > >> >> > To have better pace and better CC up-time we need
>> something
>> >> > else
>> >> > > > but
>> >> > > > >> >> not
>> >> > > > >> >> > just "stop and fix". I suggest "revert and continue"
>> >> > > > >> >>
>> >> > > > >> >> What's the difference, other than debating the
>> semantics of
>> >> > "fix"
>> >> > > > and
>> >> > > > >> >> "revert"?
>> >> > > > >> >>
>> >> > > > >> >> We all agree - but I still don't think you're clearly
>> stating
>> >> > the
>> >> > > > >> >> problem. I think that the core problem is that we don't
>> >> > > > immediately
>> >> > > > >> >> react to CC failure.
>> >> > > > >> >>
>> >> > > > >> >> Immediately reacting to CC failure should be the first
>> >> order of
>> >> > > > the
>> >> > > > >day
>> >> > > > >> >> here. Reacting to me is making the decision, quickly,
>> about
>> >> > > > either
>> >> > > > >> >> rolling back the change ("reverting") or doing something
>> >> else.
>> >> > > > The
>> >> > > > >key
>> >> > > > >>
>> >> > > > >> >> is being responsive.
>> >> > > > >> >>
>> >> > > > >> >> It seems that what happens is that we wait, and then sets
>> of
>> >> > > > changes
>> >> > > > >> >> pile up, and I think that doing mass rollbacks at that
>> point
>> >> > will
>> >> > > > >solve
>> >> > > > >> >> it, but make a mess.
>> >> > > > >> >>
>> >> > > > >> >> The example of what I envision is when I broke the
>> build in
>> >> > DRLVM,
>> >> > > > >> >> Gregory told me immediately, and I fixed immediately - w/o
>> a
>> >> > > > rollback.
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > > > >> >> All I'm saying is :
>> >> > > > >> >>
>> >> > > > >> >> 1) We need to be far better with reaction time
>> >> > > > >> >
>> >> > > > >> > I would say we need to be far better with fixing/reverting
>> >> time.
>> >> > > > >> > If we reacted immediately and than discussed for two weeks
>> >> -- we
>> >> > > > would
>> >> > > > >> not
>> >> > > > >> > be better than where we are now
>> >> > > > >>
>> >> > > > >> Yes, fixing/reverting is included. It's what I meant.
>> >> > > > >>
>> >> > > > >> >
>> >> > > > >> >>
>> >> > > > >> >> 2) We have intelligent people - we can be agile in this by
>> >> > making
>> >> > > > >> >> decisions (quickly!) on a case by case basis what to do.
>> >> > > > >> >>
>> >> > > > >> >> I'll also suggest that we ask each committer to check the
>> CC
>> >> > event
>> >> > > > >> >> stream before committing, so you don't commit into a bad
>> >> state
>> >> > of
>> >> > > > >> things.
>> >> > > > >> >>
>> >> > > > >> >> One of my problems is that I don't trust the CC stream,
>> and
>> >> > don't
>> >> > > > >> >> clearly see it because it's mixed in the other drek of the
>> >> > > > commits@
>> >> > > > >> list.
>> >> > > > >> >
>> >> > > > >> > The problem is intermittent failures. I suggest that we
>> >> exclude
>> >> > > > >graphics
>> >> > > > >> > tests
>> >> > > > >> > from CCs and probably have CC-specific exclude lists for
>> >> > networking
>> >> > > > >> tests
>> >> > > > >> > (or fix all the known intermittent failures right now :)
>> >> > > > >>
>> >> > > > >> good idea - works for me.
>> >> > > > >>
>> >> > > > >> We need to drive into stability - we've made amazing progress
>> in
>> >> > the
>> >> > > > >> last two months, and now we're down to the really, really
>> hard
>> >> > stuff.
>> >> > > > I
>> >> > > > >> think that excluding them to get rock-solid CC reporting is
>> >> step 0,
>> >> > > > >> and then step 1 is try and grind out the intermittent
>> failures.
>> >> > > > >>
>> >> > > > >> geir
>> >> > > > >>
>> >> > > > >>
>> >> > > >
>> >> > > > --
>> >> > > > Alexey A. Ivanov
>> >> > > > Intel Enterprise Solutions Software Division
>> >> > > >
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>>
>