potential locking problem in 1.7.0

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

potential locking problem in 1.7.0

Holger
Hey guys,

after switching to Glazed Lists 1.7.0 we're
observing occasional blocking of the
EventDispatchThread waiting for a lock.

With the tip from
http://elliotth.blogspot.com/2005/05/automatically-detecting-awt-event.html
I managed to get a stacktrace:

sun.misc.Unsafe.park(Native Method)
    java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
    java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:681)
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:711)
    java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1041)
    java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:342)
    java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:637)
    ca.odell.glazedlists.impl.java15.LockAdapter.lock(J2SE50LockFactory.java:74)
    ca.odell.glazedlists.swing.EventSelectionModel.removeSelectionInterval(EventSelectionModel.java:262)
    com.jidesoft.grid.JideTable.a(Unknown Source)
    com.jidesoft.grid.JideTable.a(Unknown Source)
    com.jidesoft.grid.JideTable.tableChanged(Unknown Source)
    com.jidesoft.grid.CellSpanTable.tableChanged(Unknown Source)
    javax.swing.table.AbstractTableModel.fireTableChanged(AbstractTableModel.java:280)
    ca.odell.glazedlists.swing.EventTableModel.listChanged(EventTableModel.java:144)
    ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:869)
    ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
    ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:435)
    ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:334)
    ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter.fireEvent(ListEventAssembler.java:855)
    ca.odell.glazedlists.event.ListEventAssembler$AssemblerHelper.commitEvent(ListEventAssembler.java:389)
    ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:226)
    ca.odell.glazedlists.BasicEventList.add(BasicEventList.java:125)
    ...

The relevant part starts with adding an element to an event list.
An EventTableModel is notified and its listChanged-method is called.
This method aquires a read lock and - while holding it - it fires a table change event.
The table (JideTable in this case) in turn calls EventSelectionModel.removeSelectionInterval(..),
which tries to aquire a write lock ... and hangs forever, because the TableModel already
holds the read lock.

With Glazed Lists 1.6 this problem didn't show up this way, because in this version
EventSelectionModel.removeSelectionInterval(...) does not aquire a write lock.
I guess, other methods are affected, too.

This seems like a bug to me. What do you think?

When we consequently lock the source list (although only accessed from the EDT in our code)
the problem doesn't show up - at least so far.

Holger

_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: potential locking problem in 1.7.0

Holger
Here is one simple testcase with a 'normal' JTable
demonstrating the problem:

public class TableTest extends TestCase {
   
    public void testLockingProblem() {        
        final BasicEventList<String> list = new BasicEventList<String>();
        list.add("Member_one");
       
        EventTableModel model = new EventTableModel<String>(list, GlazedLists.<String>tableFormat(new String[] {"bytes"}, new String[] {"Test"}));
       
        JTable table = new JTable(model);

        EventSelectionModel selectionModel = new EventSelectionModel<String>(list);      
        selectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
        table.setSelectionModel(selectionModel);
        selectionModel.setSelectionInterval(0, 0);
        System.out.println("before remove");
        list.remove(0);
        System.out.println("after remove");        
    }
}

The last System.out is never reached.

Holger

> Hey guys,
>
> after switching to Glazed Lists 1.7.0 we're
> observing occasional blocking of the
> EventDispatchThread waiting for a lock.
>
> With the tip from
> http://elliotth.blogspot.com/2005/05/automatically-detecting-awt-event.html
> I managed to get a stacktrace:
>
> sun.misc.Unsafe.park(Native Method)
>     java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
>     java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:681)
>     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:711)
>     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1041)
>     java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:342)
>     java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:637)
>     ca.odell.glazedlists.impl.java15.LockAdapter.lock(J2SE50LockFactory.java:74)
>     ca.odell.glazedlists.swing.EventSelectionModel.removeSelectionInterval(EventSelectionModel.java:262)
>     com.jidesoft.grid.JideTable.a(Unknown Source)
>     com.jidesoft.grid.JideTable.a(Unknown Source)
>     com.jidesoft.grid.JideTable.tableChanged(Unknown Source)
>     com.jidesoft.grid.CellSpanTable.tableChanged(Unknown Source)
>     javax.swing.table.AbstractTableModel.fireTableChanged(AbstractTableModel.java:280)
>     ca.odell.glazedlists.swing.EventTableModel.listChanged(EventTableModel.java:144)
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:869)
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
>     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:435)
>     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:334)
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter.fireEvent(ListEventAssembler.java:855)
>     ca.odell.glazedlists.event.ListEventAssembler$AssemblerHelper.commitEvent(ListEventAssembler.java:389)
>     ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:226)
>     ca.odell.glazedlists.BasicEventList.add(BasicEventList.java:125)
>     ...
>
> The relevant part starts with adding an element to an event list.
> An EventTableModel is notified and its listChanged-method is called.
> This method aquires a read lock and - while holding it - it fires a table change event.
> The table (JideTable in this case) in turn calls EventSelectionModel.removeSelectionInterval(..),
> which tries to aquire a write lock ... and hangs forever, because the TableModel already
> holds the read lock.
>
> With Glazed Lists 1.6 this problem didn't show up this way, because in this version
> EventSelectionModel.removeSelectionInterval(...) does not aquire a write lock.
> I guess, other methods are affected, too.
>
> This seems like a bug to me. What do you think?
>
> When we consequently lock the source list (although only accessed from the EDT in our code)
> the problem doesn't show up - at least so far.
>
> Holger
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: potential locking problem in 1.7.0

Jesse Wilson
In reply to this post by Holger
Hey Holger ---

That's a scary bug! Could you please include
the rest of the stacktrace below this line:
    ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
... in particular I want to validate that ThreadProxyEventList
is being activated.

We have a rule that says EventTableModel should only
ever be notified on the Swing EDT. If this is not happening,
we have a big problem!

Perhaps a really simple test would be to add the following
code to listChanged in EventTableModel:
   if(!SwingUtilities.isEventDispatchThread()) throw new
IllegalStateException();

I'm assuming you're using your locks correctly, acquiring
the write lock before you do the add(). Could you send me
a test case that demonstrates the problem? It looks scary
and I'll try to get it fixed ASAP!

Thanks,
Jesse


On 8/23/06, Holger Brands <[hidden email]> wrote:

> Hey guys,
>
> after switching to Glazed Lists 1.7.0 we're
> observing occasional blocking of the
> EventDispatchThread waiting for a lock.
>
> With the tip from
> http://elliotth.blogspot.com/2005/05/automatically-detecting-awt-event.html
> I managed to get a stacktrace:
>
> sun.misc.Unsafe.park(Native Method)
>     java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
>     java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:681)
>     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:711)
>     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1041)
>     java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:342)
>     java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:637)
>     ca.odell.glazedlists.impl.java15.LockAdapter.lock(J2SE50LockFactory.java:74)
>     ca.odell.glazedlists.swing.EventSelectionModel.removeSelectionInterval(EventSelectionModel.java:262)
>     com.jidesoft.grid.JideTable.a(Unknown Source)
>     com.jidesoft.grid.JideTable.a(Unknown Source)
>     com.jidesoft.grid.JideTable.tableChanged(Unknown Source)
>     com.jidesoft.grid.CellSpanTable.tableChanged(Unknown Source)
>     javax.swing.table.AbstractTableModel.fireTableChanged(AbstractTableModel.java:280)
>     ca.odell.glazedlists.swing.EventTableModel.listChanged(EventTableModel.java:144)
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:869)
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
>     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:435)
>     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:334)
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter.fireEvent(ListEventAssembler.java:855)
>     ca.odell.glazedlists.event.ListEventAssembler$AssemblerHelper.commitEvent(ListEventAssembler.java:389)
>     ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:226)
>     ca.odell.glazedlists.BasicEventList.add(BasicEventList.java:125)
>     ...
>
> The relevant part starts with adding an element to an event list.
> An EventTableModel is notified and its listChanged-method is called.
> This method aquires a read lock and - while holding it - it fires a table change event.
> The table (JideTable in this case) in turn calls EventSelectionModel.removeSelectionInterval(..),
> which tries to aquire a write lock ... and hangs forever, because the TableModel already
> holds the read lock.
>
> With Glazed Lists 1.6 this problem didn't show up this way, because in this version
> EventSelectionModel.removeSelectionInterval(...) does not aquire a write lock.
> I guess, other methods are affected, too.
>
> This seems like a bug to me. What do you think?
>
> When we consequently lock the source list (although only accessed from the EDT in our code)
> the problem doesn't show up - at least so far.
>
> Holger
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: potential locking problem in 1.7.0

Jesse Wilson
In reply to this post by Holger
I couldn't reproduce the problem on my dual core machine,
I'll try it on a single CPU box later.

Also note that the test itself has a simple flaw - you're not
locking on the add() and remove() calls. To simplify, change
the declaration of list to be this:
        final EventList<String> list = GlazedLists.threadSafeList(new
BasicEventList<String>());
 ... then all your locking is automagic.

Cheers,
Jesse

On 8/23/06, Holger Brands <[hidden email]> wrote:

> Here is one simple testcase with a 'normal' JTable
> demonstrating the problem:
>
> public class TableTest extends TestCase {
>
>     public void testLockingProblem() {
>         final BasicEventList<String> list = new BasicEventList<String>();
>         list.add("Member_one");
>
>         EventTableModel model = new EventTableModel<String>(list, GlazedLists.<String>tableFormat(new String[] {"bytes"}, new String[] {"Test"}));
>
>         JTable table = new JTable(model);
>
>         EventSelectionModel selectionModel = new EventSelectionModel<String>(list);
>         selectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
>         table.setSelectionModel(selectionModel);
>         selectionModel.setSelectionInterval(0, 0);
>         System.out.println("before remove");
>         list.remove(0);
>         System.out.println("after remove");
>     }
> }
>
> The last System.out is never reached.
>
> Holger
>
> > Hey guys,
> >
> > after switching to Glazed Lists 1.7.0 we're
> > observing occasional blocking of the
> > EventDispatchThread waiting for a lock.
> >
> > With the tip from
> > http://elliotth.blogspot.com/2005/05/automatically-detecting-awt-event.html
> > I managed to get a stacktrace:
> >
> > sun.misc.Unsafe.park(Native Method)
> >     java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
> >     java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:681)
> >     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:711)
> >     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1041)
> >     java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:342)
> >     java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:637)
> >     ca.odell.glazedlists.impl.java15.LockAdapter.lock(J2SE50LockFactory.java:74)
> >     ca.odell.glazedlists.swing.EventSelectionModel.removeSelectionInterval(EventSelectionModel.java:262)
> >     com.jidesoft.grid.JideTable.a(Unknown Source)
> >     com.jidesoft.grid.JideTable.a(Unknown Source)
> >     com.jidesoft.grid.JideTable.tableChanged(Unknown Source)
> >     com.jidesoft.grid.CellSpanTable.tableChanged(Unknown Source)
> >     javax.swing.table.AbstractTableModel.fireTableChanged(AbstractTableModel.java:280)
> >     ca.odell.glazedlists.swing.EventTableModel.listChanged(EventTableModel.java:144)
> >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:869)
> >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
> >     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:435)
> >     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:334)
> >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter.fireEvent(ListEventAssembler.java:855)
> >     ca.odell.glazedlists.event.ListEventAssembler$AssemblerHelper.commitEvent(ListEventAssembler.java:389)
> >     ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:226)
> >     ca.odell.glazedlists.BasicEventList.add(BasicEventList.java:125)
> >     ...
> >
> > The relevant part starts with adding an element to an event list.
> > An EventTableModel is notified and its listChanged-method is called.
> > This method aquires a read lock and - while holding it - it fires a table change event.
> > The table (JideTable in this case) in turn calls EventSelectionModel.removeSelectionInterval(..),
> > which tries to aquire a write lock ... and hangs forever, because the TableModel already
> > holds the read lock.
> >
> > With Glazed Lists 1.6 this problem didn't show up this way, because in this version
> > EventSelectionModel.removeSelectionInterval(...) does not aquire a write lock.
> > I guess, other methods are affected, too.
> >
> > This seems like a bug to me. What do you think?
> >
> > When we consequently lock the source list (although only accessed from the EDT in our code)
> > the problem doesn't show up - at least so far.
> >
> > Holger
> >
> > _______________________________________________________________________
> > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: potential locking problem in 1.7.0

Holger
In reply to this post by Holger
Hey Jesse,

ok, here is a modified test case.
All code is executed on the Swing EDT, so no locking
should be required.
If you enable the locks, the test case passes.

public class TableTest extends TestCase {
   
    public void testLockingProblem() throws InterruptedException, InvocationTargetException {        
       
        SwingUtilities.invokeAndWait(new Runnable() {
            /**
             * {@inheritDoc}
             */
            public void run() {
                final BasicEventList<String> list = new BasicEventList<String>();
                list.add("Member_one");
               
                EventTableModel model = new EventTableModel<String>(list, GlazedLists.<String>tableFormat(new String[] {"bytes"}, new String[] {"Test"}));
               
                JTable table = new JTable(model);

                EventSelectionModel selectionModel = new EventSelectionModel<String>(list);      
                selectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
                table.setSelectionModel(selectionModel);
                System.out.println("before add");
//                list.getReadWriteLock().writeLock().lock();
//                try {
                    list.add("Test");
//                } finally {
//                    list.getReadWriteLock().writeLock().unlock();
//                }
                System.out.println("after add");
                System.out.flush();
            }
        });
    }
}

> I couldn't reproduce the problem on my dual core machine,
> I'll try it on a single CPU box later.
>
> Also note that the test itself has a simple flaw - you're not
> locking on the add() and remove() calls. To simplify, change
> the declaration of list to be this:
>         final EventList<String> list = GlazedLists.threadSafeList(new
> BasicEventList<String>());
>  ... then all your locking is automagic.
>
> Cheers,
> Jesse
>
> On 8/23/06, Holger Brands <[hidden email]> wrote:
> > Here is one simple testcase with a 'normal' JTable
> > demonstrating the problem:
> >
> > public class TableTest extends TestCase {
> >
> >     public void testLockingProblem() {
> >         final BasicEventList<String> list = new BasicEventList<String>();
> >         list.add("Member_one");
> >
> >         EventTableModel model = new EventTableModel<String>(list, GlazedLists.<String>tableFormat(new String[] {"bytes"}, new String[] {"Test"}));
> >
> >         JTable table = new JTable(model);
> >
> >         EventSelectionModel selectionModel = new EventSelectionModel<String>(list);
> >         selectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
> >         table.setSelectionModel(selectionModel);
> >         selectionModel.setSelectionInterval(0, 0);
> >         System.out.println("before remove");
> >         list.remove(0);
> >         System.out.println("after remove");
> >     }
> > }
> >
> > The last System.out is never reached.
> >
> > Holger
> >
> > > Hey guys,
> > >
> > > after switching to Glazed Lists 1.7.0 we're
> > > observing occasional blocking of the
> > > EventDispatchThread waiting for a lock.
> > >
> > > With the tip from
> > > http://elliotth.blogspot.com/2005/05/automatically-detecting-awt-event.html
> > > I managed to get a stacktrace:
> > >
> > > sun.misc.Unsafe.park(Native Method)
> > >     java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
> > >     java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:681)
> > >     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:711)
> > >     java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1041)
> > >     java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:342)
> > >     java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:637)
> > >     ca.odell.glazedlists.impl.java15.LockAdapter.lock(J2SE50LockFactory.java:74)
> > >     ca.odell.glazedlists.swing.EventSelectionModel.removeSelectionInterval(EventSelectionModel.java:262)
> > >     com.jidesoft.grid.JideTable.a(Unknown Source)
> > >     com.jidesoft.grid.JideTable.a(Unknown Source)
> > >     com.jidesoft.grid.JideTable.tableChanged(Unknown Source)
> > >     com.jidesoft.grid.CellSpanTable.tableChanged(Unknown Source)
> > >     javax.swing.table.AbstractTableModel.fireTableChanged(AbstractTableModel.java:280)
> > >     ca.odell.glazedlists.swing.EventTableModel.listChanged(EventTableModel.java:144)
> > >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:869)
> > >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
> > >     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:435)
> > >     ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:334)
> > >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter.fireEvent(ListEventAssembler.java:855)
> > >     ca.odell.glazedlists.event.ListEventAssembler$AssemblerHelper.commitEvent(ListEventAssembler.java:389)
> > >     ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:226)
> > >     ca.odell.glazedlists.BasicEventList.add(BasicEventList.java:125)
> > >     ...
> > >
> > > The relevant part starts with adding an element to an event list.
> > > An EventTableModel is notified and its listChanged-method is called.
> > > This method aquires a read lock and - while holding it - it fires a table change event.
> > > The table (JideTable in this case) in turn calls EventSelectionModel.removeSelectionInterval(..),
> > > which tries to aquire a write lock ... and hangs forever, because the TableModel already
> > > holds the read lock.
> > >
> > > With Glazed Lists 1.6 this problem didn't show up this way, because in this version
> > > EventSelectionModel.removeSelectionInterval(...) does not aquire a write lock.
> > > I guess, other methods are affected, too.
> > >
> > > This seems like a bug to me. What do you think?
> > >
> > > When we consequently lock the source list (although only accessed from the EDT in our code)
> > > the problem doesn't show up - at least so far.
> > >
> > > Holger
> > >
> > > _______________________________________________________________________
> > > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: potential locking problem in 1.7.0

Holger
In reply to this post by Holger
Jesse,

> Hey Holger ---
>
> That's a scary bug! Could you please include
> the rest of the stacktrace below this line:
>     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
> ... in particular I want to validate that ThreadProxyEventList
> is being activated.

The rest of the stacktrace is only user code and not related to Glazed Lists.
The code is definitely executed on the EDT inside an actionPerfomed()-method.

> I'm assuming you're using your locks correctly, acquiring
> the write lock before you do the add().

No. The list is only accessed in the Swing EDT, so we didn't lock the list.
In the meantime, I have done this locking and it worked well.

But I still think there is a problem. If only a single thread is involved,
locking should not be required, right?

Holger


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: potential locking problem in 1.7.0

Jesse Wilson
If you only use a single thread, locking is not required.

Have you been able to reproduce the problem with a single thread?


On 8/23/06, Holger Brands <[hidden email]> wrote:

> Jesse,
>
> > Hey Holger ---
> >
> > That's a scary bug! Could you please include
> > the rest of the stacktrace below this line:
> >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
> > ... in particular I want to validate that ThreadProxyEventList
> > is being activated.
>
> The rest of the stacktrace is only user code and not related to Glazed Lists.
> The code is definitely executed on the EDT inside an actionPerfomed()-method.
>
> > I'm assuming you're using your locks correctly, acquiring
> > the write lock before you do the add().
>
> No. The list is only accessed in the Swing EDT, so we didn't lock the list.
> In the meantime, I have done this locking and it worked well.
>
> But I still think there is a problem. If only a single thread is involved,
> locking should not be required, right?
>
> Holger
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: potential locking problem in 1.7.0

James Lemieux
Jesse, I'm not sure if you're seeing Holger's problem. He has already sent you a test case that is single threaded and demonstrates the problem.

   Specifically, in Holger's test case, ALL work is done on the EDT, and when EventList.remove(0) is called 3 things happen in serial order:

1. EventTableModel.listChanged(...) acquires the readLock and then broadcasts TableModelEvents

2. The JTable receives the TableModelEvent and calls EventSelectionModel.removeSelectionInterval(...)

3. EventSelectionModel.removeSelectionInterval(...) was recently changed to acquire the writeLock... which now causes a deadlock with itself, since is already owns the readLock from step 1.

So, the problem is that Holger SHOULD be able to get away with calling EventList.remove(0) without acquiring the writeLock, since the test is single threaded, but he CANNOT because the single thread deadlocks itself with the 1.7.0 code... that is quite bad and will need to be patched ASAP. But, I don't know what the best fix is...

If step 1 was upgraded to acquire the writeLock it would fix this problem, but it reduces concurrency... is there a better fix?

James

On 8/23/06, Jesse Wilson <[hidden email]> wrote:
If you only use a single thread, locking is not required.

Have you been able to reproduce the problem with a single thread?


On 8/23/06, Holger Brands <[hidden email] > wrote:

> Jesse,
>
> > Hey Holger ---
> >
> > That's a scary bug! Could you please include
> > the rest of the stacktrace below this line:
> >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire (ListEventAssembler.java:861)
> > ... in particular I want to validate that ThreadProxyEventList
> > is being activated.
>
> The rest of the stacktrace is only user code and not related to Glazed Lists.
> The code is definitely executed on the EDT inside an actionPerfomed()-method.
>
> > I'm assuming you're using your locks correctly, acquiring
> > the write lock before you do the add().
>

> No. The list is only accessed in the Swing EDT, so we didn't lock the list.
> In the meantime, I have done this locking and it worked well.
>
> But I still think there is a problem. If only a single thread is involved,
> locking should not be required, right?
>
> Holger
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: potential locking problem in 1.7.0

Holger
In reply to this post by Holger
Jesse,

did you see and try the testcase here:
https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550

It fails for me,
Holger

> If you only use a single thread, locking is not required.
>
> Have you been able to reproduce the problem with a single thread?
>
>
> On 8/23/06, Holger Brands <[hidden email]> wrote:
> > Jesse,
> >
> > > Hey Holger ---
> > >
> > > That's a scary bug! Could you please include
> > > the rest of the stacktrace below this line:
> > >     ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:861)
> > > ... in particular I want to validate that ThreadProxyEventList
> > > is being activated.
> >
> > The rest of the stacktrace is only user code and not related to Glazed Lists.
> > The code is definitely executed on the EDT inside an actionPerfomed()-method.
> >
> > > I'm assuming you're using your locks correctly, acquiring
> > > the write lock before you do the add().
> >
> > No. The list is only accessed in the Swing EDT, so we didn't lock the list.
> > In the meantime, I have done this locking and it worked well.
> >
> > But I still think there is a problem. If only a single thread is involved,
> > locking should not be required, right?
> >
> > Holger
> >
> >
> > _______________________________________________________________________
> > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: potential locking problem in 1.7.0

Jesse Wilson
In reply to this post by James Lemieux
Hey guys ----

EventTableModel.listChanged() should NOT be acquiring
any locks, it is assumed that the locks are already held.

The read/write locks should be reentrant, but it makes sense
that you can't acquire a write lock after a read lock - if 2
threads were to do this deadlock would be guaranteed.

That's the bug, plain and simple. I'll remove the offending
lock acquires in EventTableModel.

Curiously, the problem doesn't show up on my Mac - I imagine
the locks are different somehow?

Cheers,
Jesse


On 8/23/06, James Lemieux <[hidden email]> wrote:

> Jesse, I'm not sure if you're seeing Holger's problem. He has already sent
> you a test case that is single threaded and demonstrates the problem.
>
>    Specifically, in Holger's test case, ALL work is done on the EDT, and
> when EventList.remove(0) is called 3 things happen in serial order:
>
> 1. EventTableModel.listChanged(...) acquires the readLock and then
> broadcasts TableModelEvents
>
> 2. The JTable receives the TableModelEvent and calls
> EventSelectionModel.removeSelectionInterval(...)
>
> 3. EventSelectionModel.removeSelectionInterval(...) was
> recently changed to acquire the writeLock... which now causes a deadlock
> with itself, since is already owns the readLock from step 1.
>
> So, the problem is that Holger SHOULD be able to get away with calling
> EventList.remove(0) without acquiring the writeLock, since the test is
> single threaded, but he CANNOT because the single thread deadlocks itself
> with the 1.7.0 code... that is quite bad and will need to be patched ASAP.
> But, I don't know what the best fix is...
>
> If step 1 was upgraded to acquire the writeLock it would fix this problem,
> but it reduces concurrency... is there a better fix?
>
> James
>
>
> On 8/23/06, Jesse Wilson <[hidden email]> wrote:
> > If you only use a single thread, locking is not required.
> >
> > Have you been able to reproduce the problem with a single thread?
> >
> >
> > On 8/23/06, Holger Brands <[hidden email] > wrote:
> > > Jesse,
> > >
> > > > Hey Holger ---
> > > >
> > > > That's a scary bug! Could you please include
> > > > the rest of the stacktrace below this line:
> > > >
> ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire
> (ListEventAssembler.java:861)
> > > > ... in particular I want to validate that ThreadProxyEventList
> > > > is being activated.
> > >
> > > The rest of the stacktrace is only user code and not related to Glazed
> Lists.
> > > The code is definitely executed on the EDT inside an
> actionPerfomed()-method.
> > >
> > > > I'm assuming you're using your locks correctly, acquiring
> > > > the write lock before you do the add().
> > >
> > > No. The list is only accessed in the Swing EDT, so we didn't lock the
> list.
> > > In the meantime, I have done this locking and it worked well.
> > >
> > > But I still think there is a problem. If only a single thread is
> involved,
> > > locking should not be required, right?
> > >
> > > Holger
> > >
> > >
> > >
> _______________________________________________________________________
> > > Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> > > Gleich testen!
> http://www.pc-sicherheit.web.de/freescan/?mc=022222
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [hidden email]
> > > For additional commands, e-mail:
> [hidden email]
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: potential locking problem in 1.7.0

Jesse Wilson
In reply to this post by Holger
On 8/23/06, Holger Brands <[hidden email]> wrote:
> did you see and try the testcase here:
> https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550

That test case pases on my Mac. Possibly a
difference in VM.

Regardless, it's a problem. I'll open a defect in our
bugtracker. Do you think we should cut a 1.7.1 for
this problem?

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: potential locking problem in 1.7.0

James Lemieux
I actually do think we should ship a 1.7.1. This could be a potential nightmare for users, and it IS newly introduced, so the responsible thing to do is to be proactive.

We've also gotta make sure the test makes it into our test suite. Good find and diagnosis Holger.

James

On 8/23/06, Jesse Wilson <[hidden email]> wrote:
On 8/23/06, Holger Brands <[hidden email]> wrote:
> did you see and try the testcase here:
> https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550

That test case pases on my Mac. Possibly a
difference in VM.

Regardless, it's a problem. I'll open a defect in our
bugtracker. Do you think we should cut a 1.7.1 for
this problem?

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: potential locking problem in 1.7.0

Holger
In reply to this post by Holger
Hey Jesse,

> On 8/23/06, Holger Brands <[hidden email]> wrote:
> > did you see and try the testcase here:
> > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
>
> That test case pases on my Mac. Possibly a
> difference in VM.

Or perhaps differences in the JTable implementation?
I tested with Sun JRE 1.5.
You could recheck how the JTable.tableChanged(..) is
implemented. Does it callback the SelectionModel?

> Regardless, it's a problem. I'll open a defect in our
> bugtracker. Do you think we should cut a 1.7.1 for
> this problem?

I think so.

Thanks,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

Jesse Wilson
Rock on boys. Well a 1.7.1 there shall be.
I have NOT implemented the fix because I can't
reproduce it, and I really don't like fixing bugs I
can't see!

If either of you would please make a fix and
quietly push out a 1.7.1, that would be swell.
We need a really fast process to put out these
sort of bugfix releases since currently doing a
release is really labour intensive.

Also - has anything else changed in the interim
since 1.7.0? If we've changed stuff, it might
be worthwhile to apply the fix to our CVS tagged
1.7.0 version rather than our current code?

As for pushing out the release, here's the release
instructions. If you have questions, let me know!
http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release

Cheers,
Jesse

On 8/23/06, Holger Brands <[hidden email]> wrote:

> Hey Jesse,
>
> > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > did you see and try the testcase here:
> > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> >
> > That test case pases on my Mac. Possibly a
> > difference in VM.
>
> Or perhaps differences in the JTable implementation?
> I tested with Sun JRE 1.5.
> You could recheck how the JTable.tableChanged(..) is
> implemented. Does it callback the SelectionModel?
>
> > Regardless, it's a problem. I'll open a defect in our
> > bugtracker. Do you think we should cut a 1.7.1 for
> > this problem?
>
> I think so.
>
> Thanks,
> Holger
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

Holger
In reply to this post by Holger
Hey Jesse,

are you sure that the fix (removing the locks from
EventTableModel.listChanged) has no side-effects?

While I agree that we should release a 1.7.1 quickly,
we also should ensure that the fix doesn't break
anything else.
I could make a latest build with the proposed fix tonight,
so we could test it a bit more.
On the weekend I would probably have some time to
make a 1.7.1 release.

Since the 1.7.0 release I added the hibernate extension, but made
no major changes to existing stuff, I think.

Holger

> Rock on boys. Well a 1.7.1 there shall be.
> I have NOT implemented the fix because I can't
> reproduce it, and I really don't like fixing bugs I
> can't see!
>
> If either of you would please make a fix and
> quietly push out a 1.7.1, that would be swell.
> We need a really fast process to put out these
> sort of bugfix releases since currently doing a
> release is really labour intensive.
>
> Also - has anything else changed in the interim
> since 1.7.0? If we've changed stuff, it might
> be worthwhile to apply the fix to our CVS tagged
> 1.7.0 version rather than our current code?
>
> As for pushing out the release, here's the release
> instructions. If you have questions, let me know!
> http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release
>
> Cheers,
> Jesse
>
> On 8/23/06, Holger Brands <[hidden email]> wrote:
> > Hey Jesse,
> >
> > > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > > did you see and try the testcase here:
> > > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> > >
> > > That test case pases on my Mac. Possibly a
> > > difference in VM.
> >
> > Or perhaps differences in the JTable implementation?
> > I tested with Sun JRE 1.5.
> > You could recheck how the JTable.tableChanged(..) is
> > implemented. Does it callback the SelectionModel?
> >
> > > Regardless, it's a problem. I'll open a defect in our
> > > bugtracker. Do you think we should cut a 1.7.1 for
> > > this problem?
> >
> > I think so.
> >
> > Thanks,
> > Holger
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

James Lemieux
Since the release I've done a bunch of work on treetable (who cares) and the demo applications (but IssuesBrowser appears to be working great). I have no work that is only partially completed.

I agree with the theory of your fix Jesse: EventTableModel.listChanged should not be acquiring the read lock... it should have been acquired by the user well before that time, if they need to protect concurrent access.

Holger is right though, we need at least a small "QA cycle" to regression test the fix. Maybe a week of running it in the wild... I'll install the proposed 1.7.1 build at work and test passively during that time as well.

I tried installing Windows Vista beta 2 last night, received an error message about an hour into the installation, and it aborted the installation and rolled back to my old Windows XP setup. The error message said something about an inability to install the default language... It's hard for me to give them beta feedback when I can't install it!

James

On 8/24/06, Holger Brands <[hidden email]> wrote:
Hey Jesse,

are you sure that the fix (removing the locks from
EventTableModel.listChanged) has no side-effects?

While I agree that we should release a 1.7.1 quickly,
we also should ensure that the fix doesn't break
anything else.
I could make a latest build with the proposed fix tonight,
so we could test it a bit more.
On the weekend I would probably have some time to
make a 1.7.1 release.

Since the 1.7.0 release I added the hibernate extension, but made
no major changes to existing stuff, I think.

Holger

> Rock on boys. Well a 1.7.1 there shall be.
> I have NOT implemented the fix because I can't
> reproduce it, and I really don't like fixing bugs I
> can't see!
>
> If either of you would please make a fix and
> quietly push out a 1.7.1, that would be swell.
> We need a really fast process to put out these
> sort of bugfix releases since currently doing a
> release is really labour intensive.
>
> Also - has anything else changed in the interim
> since 1.7.0? If we've changed stuff, it might
> be worthwhile to apply the fix to our CVS tagged
> 1.7.0 version rather than our current code?

>
> As for pushing out the release, here's the release
> instructions. If you have questions, let me know!
> http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release
>
> Cheers,
> Jesse
>
> On 8/23/06, Holger Brands <[hidden email]> wrote:
> > Hey Jesse,
> >
> > > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > > did you see and try the testcase here:
> > > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> > >
> > > That test case pases on my Mac. Possibly a
> > > difference in VM.
> >
> > Or perhaps differences in the JTable implementation?
> > I tested with Sun JRE 1.5.
> > You could recheck how the JTable.tableChanged(..) is
> > implemented. Does it callback the SelectionModel?
> >
> > > Regardless, it's a problem. I'll open a defect in our
> > > bugtracker. Do you think we should cut a 1.7.1 for
> > > this problem?

> >
> > I think so.
> >
> > Thanks,
> > Holger
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

James Lemieux
In reply to this post by Jesse Wilson
I don't think anything major has been done to destabilize the code base since 1.7.0 shipped. I think we're fine to fix the latest and ship that as a 1.7.1.

James

On 8/23/06, Jesse Wilson <[hidden email]> wrote:
Rock on boys. Well a 1.7.1 there shall be.
I have NOT implemented the fix because I can't
reproduce it, and I really don't like fixing bugs I
can't see!

If either of you would please make a fix and
quietly push out a 1.7.1, that would be swell.
We need a really fast process to put out these
sort of bugfix releases since currently doing a
release is really labour intensive.

Also - has anything else changed in the interim
since 1.7.0? If we've changed stuff, it might
be worthwhile to apply the fix to our CVS tagged
1.7.0 version rather than our current code?

As for pushing out the release, here's the release
instructions. If you have questions, let me know!
http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release

Cheers,
Jesse

On 8/23/06, Holger Brands <[hidden email] > wrote:

> Hey Jesse,
>
> > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > did you see and try the testcase here:
> > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> >
> > That test case pases on my Mac. Possibly a
> > difference in VM.
>
> Or perhaps differences in the JTable implementation?
> I tested with Sun JRE 1.5.
> You could recheck how the JTable.tableChanged(..) is
> implemented. Does it callback the SelectionModel?
>
> > Regardless, it's a problem. I'll open a defect in our
> > bugtracker. Do you think we should cut a 1.7.1 for
> > this problem?
>
> I think so.
>
> Thanks,
> Holger
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

Holger
In reply to this post by Holger
Hey guys,

I've uploaded a new latest build with the fix for EventTableModel and tests.
The change didn't break any other tests.

In the SWT extension there are the following classes
EventComboViewer
EventListViewer
EventTableViewer

which also aquire a read lock in their listChanged-method.
Please review these classes as I'm no SWT expert.

There are two quite new testcases failing:

TreeListTest.testInsertRealOverVirtualParent
AutoCompleteSupportTest.guiTestUninstall

And last but not least, there are 32 errors compiling
the tests in the java 14 build.
We should fix these in the near future, I think.

Ok, I'm offline for today...

Holger

> Since the release I've done a bunch of work on treetable (who cares) and the demo applications (but IssuesBrowser appears to be working great). I have no work that is only partially completed.
>
> I agree with the theory of your fix Jesse: EventTableModel.listChanged should not be acquiring the read lock... it should have been acquired by the user well before that time, if they need to protect concurrent access.
>
> Holger is right though, we need at least a small "QA cycle" to regression test the fix. Maybe a week of running it in the wild... I'll install the proposed 1.7.1 build at work and test passively during that time as well.
>
> I tried installing Windows Vista beta 2 last night, received an error message about an hour into the installation, and it aborted the installation and rolled back to my old Windows XP setup. The error message said something about an inability to install the default language... It's hard for me to give them beta feedback when I can't install it!
>
>
> James
>
>
> On 8/24/06, Holger Brands <[hidden email]> wrote:
> Hey Jesse,
>
> are you sure that the fix (removing the locks from
> EventTableModel.listChanged) has no side-effects?
>
> While I agree that we should release a 1.7.1 quickly,
> we also should ensure that the fix doesn't break
>
> anything else.
> I could make a latest build with the proposed fix tonight,
> so we could test it a bit more.
> On the weekend I would probably have some time to
> make a 1.7.1 release.
>
> Since the 1.7.0 release I added the hibernate extension, but made
>
> no major changes to existing stuff, I think.
>
> Holger
>
> > Rock on boys. Well a 1.7.1 there shall be.
> > I have NOT implemented the fix because I can't
> > reproduce it, and I really don't like fixing bugs I
>
> > can't see!
> >
> > If either of you would please make a fix and
> > quietly push out a 1.7.1, that would be swell.
> > We need a really fast process to put out these
> > sort of bugfix releases since currently doing a
>
> > release is really labour intensive.
> >
> > Also - has anything else changed in the interim
> > since 1.7.0? If we've changed stuff, it might
> > be worthwhile to apply the fix to our CVS tagged
> > 1.7.0 version rather than our current code?
> >
> > As for pushing out the release, here's the release
> > instructions. If you have questions, let me know!
> >
> http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release
> >
> > Cheers,
> > Jesse
> >
> > On 8/23/06, Holger Brands <
> [hidden email]> wrote:
> > > Hey Jesse,
> > >
> > > > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > > > did you see and try the testcase here:
>
> > > > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> > > >
> > > > That test case pases on my Mac. Possibly a
>
> > > > difference in VM.
> > >
> > > Or perhaps differences in the JTable implementation?
> > > I tested with Sun JRE 1.5.
> > > You could recheck how the JTable.tableChanged(..) is
>
> > > implemented. Does it callback the SelectionModel?
> > >
> > > > Regardless, it's a problem. I'll open a defect in our
> > > > bugtracker. Do you think we should cut a 1.7.1 for
> > > > this problem?
> > >
> > > I think so.
> > >
> > > Thanks,
> > > Holger
> > >
> > > _____________________________________________________________________
> > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
>
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>


__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

James Lemieux
Good stuff Holger.

If you create / upload the 1.7.1 jars over the weekend, I'll update Glazed List's main page to link to the 1.7.1 release jars, rather than 1.7.0.

Also, tonight I'll look into the failures in AutoCompleteSupportTest.guiTestUninstall as well as the compilation problems, and patch those up.

James

 

On 8/24/06, Holger Brands <[hidden email]> wrote:
Hey guys,

I've uploaded a new latest build with the fix for EventTableModel and tests.
The change didn't break any other tests.

In the SWT extension there are the following classes
EventComboViewer
EventListViewer
EventTableViewer

which also aquire a read lock in their listChanged-method.
Please review these classes as I'm no SWT expert.

There are two quite new testcases failing:

TreeListTest.testInsertRealOverVirtualParent
AutoCompleteSupportTest.guiTestUninstall

And last but not least, there are 32 errors compiling
the tests in the java 14 build.
We should fix these in the near future, I think.

Ok, I'm offline for today...

Holger

> Since the release I've done a bunch of work on treetable (who cares) and the demo applications (but IssuesBrowser appears to be working great). I have no work that is only partially completed.
>
> I agree with the theory of your fix Jesse: EventTableModel.listChanged should not be acquiring the read lock... it should have been acquired by the user well before that time, if they need to protect concurrent access.
>
> Holger is right though, we need at least a small "QA cycle" to regression test the fix. Maybe a week of running it in the wild... I'll install the proposed 1.7.1 build at work and test passively during that time as well.
>
> I tried installing Windows Vista beta 2 last night, received an error message about an hour into the installation, and it aborted the installation and rolled back to my old Windows XP setup. The error message said something about an inability to install the default language... It's hard for me to give them beta feedback when I can't install it!
>
>
> James
>
>
> On 8/24/06, Holger Brands <[hidden email]> wrote:
> Hey Jesse,
>
> are you sure that the fix (removing the locks from
> EventTableModel.listChanged) has no side-effects?
>
> While I agree that we should release a 1.7.1 quickly,
> we also should ensure that the fix doesn't break
>
> anything else.
> I could make a latest build with the proposed fix tonight,
> so we could test it a bit more.
> On the weekend I would probably have some time to
> make a 1.7.1 release.
>
> Since the 1.7.0 release I added the hibernate extension, but made
>
> no major changes to existing stuff, I think.

>
> Holger
>
> > Rock on boys. Well a 1.7.1 there shall be.
> > I have NOT implemented the fix because I can't
> > reproduce it, and I really don't like fixing bugs I
>
> > can't see!
> >
> > If either of you would please make a fix and
> > quietly push out a 1.7.1, that would be swell.
> > We need a really fast process to put out these
> > sort of bugfix releases since currently doing a
>
> > release is really labour intensive.
> >
> > Also - has anything else changed in the interim
> > since 1.7.0? If we've changed stuff, it might
> > be worthwhile to apply the fix to our CVS tagged
> > 1.7.0 version rather than our current code?
> >
> > As for pushing out the release, here's the release
> > instructions. If you have questions, let me know!
> >
> http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release
> >
> > Cheers,
> > Jesse
> >
> > On 8/23/06, Holger Brands <
> [hidden email]> wrote:
> > > Hey Jesse,
> > >
> > > > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > > > did you see and try the testcase here:
>
> > > > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> > > >
> > > > That test case pases on my Mac. Possibly a
>
> > > > difference in VM.
> > >
> > > Or perhaps differences in the JTable implementation?
> > > I tested with Sun JRE 1.5.
> > > You could recheck how the JTable.tableChanged(..) is
>
> > > implemented. Does it callback the SelectionModel?
> > >
> > > > Regardless, it's a problem. I'll open a defect in our
> > > > bugtracker. Do you think we should cut a 1.7.1 for
> > > > this problem?
> > >
> > > I think so.
> > >
> > > Thanks,
> > > Holger
> > >
> > > _____________________________________________________________________
> > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
>
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>


__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Re: potential locking problem in 1.7.0

James Lemieux
In reply to this post by Holger
Hey Holger,

   AutoCompleteSupportTest.guiTestUninstall is now fixed.

   As are the JDK 1.4 build problems in the tests.

   I'm leaving the TreeListTest breakage to Jesse...

James

On 8/24/06, Holger Brands <[hidden email]> wrote:
Hey guys,

I've uploaded a new latest build with the fix for EventTableModel and tests.
The change didn't break any other tests.

In the SWT extension there are the following classes
EventComboViewer
EventListViewer
EventTableViewer

which also aquire a read lock in their listChanged-method.
Please review these classes as I'm no SWT expert.

There are two quite new testcases failing:

TreeListTest.testInsertRealOverVirtualParent
AutoCompleteSupportTest.guiTestUninstall

And last but not least, there are 32 errors compiling
the tests in the java 14 build.
We should fix these in the near future, I think.

Ok, I'm offline for today...

Holger

> Since the release I've done a bunch of work on treetable (who cares) and the demo applications (but IssuesBrowser appears to be working great). I have no work that is only partially completed.
>

> I agree with the theory of your fix Jesse: EventTableModel.listChanged should not be acquiring the read lock... it should have been acquired by the user well before that time, if they need to protect concurrent access.
>
> Holger is right though, we need at least a small "QA cycle" to regression test the fix. Maybe a week of running it in the wild... I'll install the proposed 1.7.1 build at work and test passively during that time as well.
>
> I tried installing Windows Vista beta 2 last night, received an error message about an hour into the installation, and it aborted the installation and rolled back to my old Windows XP setup. The error message said something about an inability to install the default language... It's hard for me to give them beta feedback when I can't install it!
>
>
> James
>
>
> On 8/24/06, Holger Brands <[hidden email]> wrote:
> Hey Jesse,
>
> are you sure that the fix (removing the locks from
> EventTableModel.listChanged) has no side-effects?
>
> While I agree that we should release a 1.7.1 quickly,
> we also should ensure that the fix doesn't break
>
> anything else.
> I could make a latest build with the proposed fix tonight,
> so we could test it a bit more.
> On the weekend I would probably have some time to
> make a 1.7.1 release.
>
> Since the 1.7.0 release I added the hibernate extension, but made
>
> no major changes to existing stuff, I think.

>
> Holger
>
> > Rock on boys. Well a 1.7.1 there shall be.
> > I have NOT implemented the fix because I can't
> > reproduce it, and I really don't like fixing bugs I
>
> > can't see!
> >
> > If either of you would please make a fix and
> > quietly push out a 1.7.1, that would be swell.
> > We need a really fast process to put out these
> > sort of bugfix releases since currently doing a
>
> > release is really labour intensive.
> >
> > Also - has anything else changed in the interim
> > since 1.7.0? If we've changed stuff, it might
> > be worthwhile to apply the fix to our CVS tagged
> > 1.7.0 version rather than our current code?
> >
> > As for pushing out the release, here's the release
> > instructions. If you have questions, let me know!
> >
> http://publicobject.com/glazedlists/wiki/index.php?title=ReleaseChecklist#Building_and_Posting_the_Release
> >
> > Cheers,
> > Jesse
> >
> > On 8/23/06, Holger Brands <
> [hidden email]> wrote:
> > > Hey Jesse,
> > >
> > > > On 8/23/06, Holger Brands <[hidden email]> wrote:
> > > > > did you see and try the testcase here:
>
> > > > > https://glazedlists.dev.java.net/servlets/ReadMsg?list=dev&msgNo=550
> > > >
> > > > That test case pases on my Mac. Possibly a
>
> > > > difference in VM.
> > >
> > > Or perhaps differences in the JTable implementation?
> > > I tested with Sun JRE 1.5.
> > > You could recheck how the JTable.tableChanged(..) is
>
> > > implemented. Does it callback the SelectionModel?
> > >
> > > > Regardless, it's a problem. I'll open a defect in our
> > > > bugtracker. Do you think we should cut a 1.7.1 for
> > > > this problem?
> > >
> > > I think so.
> > >
> > > Thanks,
> > > Holger
> > >
> > > _____________________________________________________________________
> > > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
>
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>


__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


12