Nabble - GlazedLists

Re: State of Delete Giving Deleted Object

2008-10-07T16:24:37Z

I'd give more info to the abstract methods, in case the concrete implementations need it:

abstract void itemAdded(EventList<E> source, int index, E newValue);
abstract void itemRemoved(EventList<E> source, int index, E oldValue);
abstract void itemUpdated(EventList<E> source, int index, E oldValue, E newValue);

but otherwise, yeah, that's what I was thinking.

James

On Tue, Oct 7, 2008 at 3:31 PM, Sam Berlin <sberlin@...> wrote:

Thanks very much for the answer, James, and also for the pointer to
the calculations API. Unfortunately this isn't for use with
calculations, so I can't use that. Off the top of my head, I can
think of a simple AbstractListener that's something like this:

abstract AbstractListEventListener implements ListEventListener {
private List items = new ArrayList();
public void listChanged(ListEvent changes) {
while(changes.next()) {
int type = changes.getType();
int idx = changes.getChangeIndex();
switch(type) {
case ListEvent.INSERT:
items.add(idx , changes.getSourceList().get(idx);
itemAdded(items.get(idx));
break;
case ListEvent.DELETE:
Object removed = items.remove(idx);
itemRemoved(removed);
break;
case ListEvent.UPDATE:
items.set(idx , changes.getSourceList().get(idx);
itemUpdated(items.get(idx));
break;
}
}
}

abstract void itemAdded(Object o);
abstract void itemRemoved(Object o);
abstract void itemUpdated(Object o);
}

Do you see any obvious problems with something like that?

Thanks,
Sam

On Tue, Oct 7, 2008 at 6:16 PM, James Lemieux <jplemieux@...> wrote:
> At this point I'd call that work "stalled". There are about 3 or 4 really
> difficult EventLists that need serious rewrites to finish off this task.
>
> At this point I'd recommend that you consider writing a generic solution to
> this problem in your own codebase. i.e. something like your own
> AbstractListEventListener, or perhaps a ListEventSupport class, that manages
> the cached List and provides the deleted / old value at a given index.
>
> I realize that's less than ideal, but unfortunately life is catching up to
> the contributors a lot and we're not finding as much time to dedicate to
> this project. I do my best to help support what does exist, but it's not
> near what we used to do...
>
> James
>
> PS I'll mention again that if any of this is in regards to computing a
> single value from an EventList, you should seriously consider using the
> Calculations API.
>
> James
>
> On Tue, Oct 7, 2008 at 3:00 PM, Sam Berlin <sberlin@...> wrote:
>>
>> Hi All,
>>
>> I was wondering, is there progress at all on the ListEvent.DELETE
>> change providing the deleted item? I continue to stumble across this
>> while building ListEventListeners. The workaround is always to build
>> a cached copy of the list contents. That workaround seems to be
>> horribly inefficient in that every place that should just be listening
>> on the list (and needs to update state based on removed objects) needs
>> to keep a duplicate copy of the list.
>>
>> Is there any automagical code that can provide the deleted item
>> without having each listener keep its own internal state?
>>
>> Thanks much,
>> Sam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: State of Delete Giving Deleted Object

2008-10-07T15:31:21Z

Thanks very much for the answer, James, and also for the pointer to
the calculations API. Unfortunately this isn't for use with
calculations, so I can't use that. Off the top of my head, I can
think of a simple AbstractListener that's something like this:

abstract AbstractListEventListener implements ListEventListener {
private List items = new ArrayList();
public void listChanged(ListEvent changes) {
while(changes.next()) {
int type = changes.getType();
int idx = changes.getChangeIndex();
switch(type) {
case ListEvent.INSERT:
items.add(idx , changes.getSourceList().get(idx);
itemAdded(items.get(idx));
break;
case ListEvent.DELETE:
Object removed = items.remove(idx);
itemRemoved(removed);
break;
case ListEvent.UPDATE:
items.set(idx , changes.getSourceList().get(idx);
itemUpdated(items.get(idx));
break;
}
}
}

abstract void itemAdded(Object o);
abstract void itemRemoved(Object o);
abstract void itemUpdated(Object o);
}

Do you see any obvious problems with something like that?

Thanks,
Sam

On Tue, Oct 7, 2008 at 6:16 PM, James Lemieux <jplemieux@...> wrote:

> At this point I'd call that work "stalled". There are about 3 or 4 really
> difficult EventLists that need serious rewrites to finish off this task.
>
> At this point I'd recommend that you consider writing a generic solution to
> this problem in your own codebase. i.e. something like your own
> AbstractListEventListener, or perhaps a ListEventSupport class, that manages
> the cached List and provides the deleted / old value at a given index.
>
> I realize that's less than ideal, but unfortunately life is catching up to
> the contributors a lot and we're not finding as much time to dedicate to
> this project. I do my best to help support what does exist, but it's not
> near what we used to do...
>
> James
>
> PS I'll mention again that if any of this is in regards to computing a
> single value from an EventList, you should seriously consider using the
> Calculations API.
>
> James
>
> On Tue, Oct 7, 2008 at 3:00 PM, Sam Berlin <sberlin@...> wrote:
>>
>> Hi All,
>>
>> I was wondering, is there progress at all on the ListEvent.DELETE
>> change providing the deleted item? I continue to stumble across this
>> while building ListEventListeners. The workaround is always to build
>> a cached copy of the list contents. That workaround seems to be
>> horribly inefficient in that every place that should just be listening
>> on the list (and needs to update state based on removed objects) needs
>> to keep a duplicate copy of the list.
>>
>> Is there any automagical code that can provide the deleted item
>> without having each listener keep its own internal state?
>>
>> Thanks much,
>> Sam
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: State of Delete Giving Deleted Object

2008-10-07T15:16:59Z

At this point I'd call that work "stalled". There are about 3 or 4 really difficult EventLists that need serious rewrites to finish off this task.

At this point I'd recommend that you consider writing a generic solution to this problem in your own codebase. i.e. something like your own AbstractListEventListener, or perhaps a ListEventSupport class, that manages the cached List and provides the deleted / old value at a given index.

I realize that's less than ideal, but unfortunately life is catching up to the contributors a lot and we're not finding as much time to dedicate to this project. I do my best to help support what does exist, but it's not near what we used to do...

James

PS I'll mention again that if any of this is in regards to computing a single value from an EventList, you should seriously consider using the Calculations API.

James

On Tue, Oct 7, 2008 at 3:00 PM, Sam Berlin <sberlin@...> wrote:

Hi All,

I was wondering, is there progress at all on the ListEvent.DELETE
change providing the deleted item? I continue to stumble across this
while building ListEventListeners. The workaround is always to build
a cached copy of the list contents. That workaround seems to be
horribly inefficient in that every place that should just be listening
on the list (and needs to update state based on removed objects) needs
to keep a duplicate copy of the list.

Is there any automagical code that can provide the deleted item
without having each listener keep its own internal state?

Thanks much,
Sam

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

State of Delete Giving Deleted Object

2008-10-07T15:00:15Z

Hi All,

I was wondering, is there progress at all on the ListEvent.DELETE
change providing the deleted item? I continue to stumble across this
while building ListEventListeners. The workaround is always to build
a cached copy of the list contents. That workaround seems to be
horribly inefficient in that every place that should just be listening
on the list (and needs to update state based on removed objects) needs
to keep a duplicate copy of the list.

Is there any automagical code that can provide the deleted item
without having each listener keep its own internal state?

Thanks much,
Sam

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: Issue with SeparatorLists and FilterLists

2008-10-07T09:47:45Z

Neil,

Yes I tried your test case and it reproduces the problem. I haven't had enough time to dig deeper, but I believe it is a symptom of a longstanding deeper problem. Some lists that deal with groups (GroupingList, UniqueList, SeparatorList) have trouble processing a ListEvent with multiple updates in it. The last person that stumbled onto this bug and mentioned it on the forums did so about a year ago I think. At this point coding around the problem is your best option because our analysis a year ago indicated the problem was design oriented and would require substantial changes to the EventLists mentioned above.

James

On Tue, Oct 7, 2008 at 7:59 AM, neil hart <neilahart@...> wrote:

We are going to need to code around this problem. It will be an inefficient solution but this is causing our lists to stop working with exceptions.

We can probably build some more examples it that helps.

Thanks
Neil

From forum: GlazedLists - User

Re: Issue with SeparatorLists and FilterLists

2008-10-07T07:59:34Z

We are going to need to code around this problem. It will be an inefficient solution but this is causing our lists to stop working with exceptions.

We can probably build some more examples it that helps.

Thanks

Neil

From forum: GlazedLists - User

Re: More flexibility in the OSGi manifest headers

2008-10-06T01:15:53Z

Barend,

I have added your changes to source control and updated the latest jars here.

Please try it out and let me know if you experience any troubles.

James

On Sun, Sep 28, 2008 at 1:15 PM, W.B. Garvelink <barend.garvelink@...> wrote:

Hi Jesse,

I have attached a bnd definitions file and an modified ant task to
issue #454 in the tracker. The version I uploaded doesn't delete the
original JAR file but puts the OSGi file alongside it for easy
comparison. After checking the two, you may want to introduce a delete
and rename like there were there before.

I had to duplicate the JAR metadata in the .bnd file. You may want to
remove it from the ant build, but I'll leave that up to you.

Regards,
Barend

On Sun, Sep 21, 2008 at 4:52 PM, W.B. Garvelink

<barend.garvelink@...> wrote:

> I mentioned last week that I should have an updated bnd definition by
> about now. Altough I have made some progress, I'm not yet satisfied
> with the results and I'm going to take some more time. I'll check back
> in next weekend.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: GlazedLists - Dev

Re: Issue with SeparatorLists and FilterLists

2008-10-03T09:00:14Z

Hey,

I was wondering if anyone out there was at least able to reproduce this error. See below for steps on how to reproduce and the error that I am seeing. I have attached the code to this email.

Thanks,
Andrew

On Thu, Sep 18, 2008 at 11:41 AM, Andrew Gotte <andrew.gotte@...> wrote:

I am having issues with SeparatorLists wrapped around FilterLists. I wrote a simplified test case and attached it to this email.

To reproduce the issue:

1) Run the attached app
2) Set "Column 0 filter" to "Mali"
3) Set "Column 1 filter" to "Neil"
4) Set "Column 2 filter" to "Andrew"
5) Set "Column 3 filter" to "Ross"
6) Set "Group By" to "Column 4"
7) Set "Column 0 filter" to "All"

and I get the exception below:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
    at ca.odell.glazedlists.impl.adt.barcode2.FourColorTree.convertIndexColor(FourColorTree.java:677)
    at ca.odell.glazedlists.impl.event.Tree4Deltas.targetUpdate(Tree4Deltas.java:85)
    at ca.odell.glazedlists.event.ListEventAssembler$Tree4DeltasAssembler.addChange(ListEventAssembler.java:612)
    at ca.odell.glazedlists.event.ListEventAssembler.addChange(ListEventAssembler.java:158)
    at ca.odell.glazedlists.event.ListEventAssembler.addChange(ListEventAssembler.java:168)
    at ca.odell.glazedlists.event.ListEventAssembler.addUpdate(ListEventAssembler.java:195)
    at ca.odell.glazedlists.SeparatorList$SeparatorInjectorList$GrouperClient.groupChanged(SeparatorList.java:542)
    at ca.odell.glazedlists.impl.Grouper.listChanged(Grouper.java:163)
    at ca.odell.glazedlists.SeparatorList$SeparatorInjectorList.listChanged(SeparatorList.java:513)
    at ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter$ListEventFormat.fire(ListEventAssembler.java:840)
    at ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:388)
    at ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:286)
    at ca.odell.glazedlists.event.ListEventAssembler$ListSequencePublisherAdapter.fireEvent(ListEventAssembler.java:821)
    at ca.odell.glazedlists.event.ListEventAssembler$AssemblerHelper.commitEvent(ListEventAssembler.java:435)
    at ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:259)
    at ca.odell.glazedlists.FilterList.changed(FilterList.java:345)
    at ca.odell.glazedlists.FilterList.changeMatcher(FilterList.java:242)
    at ca.odell.glazedlists.FilterList.changeMatcherWithLocks(FilterList.java:215)
    at ca.odell.glazedlists.FilterList.setMatcher(FilterList.java:117)
    at com.creditex.glazedlists.separatorlistbug.SeparatorListBug$2.actionPerformed(SeparatorListBug.java:143)
    at javax.swing.JComboBox.fireActionEvent(JComboBox.java:1197)
    at javax.swing.JComboBox.setSelectedItem(JComboBox.java:561)
    at javax.swing.JComboBox.setSelectedIndex(JComboBox.java:597)
    at javax.swing.plaf.basic.BasicComboPopup$Handler.mouseReleased(BasicComboPopup.java:808)
    at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:232)
    at java.awt.Component.processMouseEvent(Component.java:5517)
    at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
    at javax.swing.plaf.basic.BasicComboPopup$1.processMouseEvent(BasicComboPopup.java:476)
    at java.awt.Component.processEvent(Component.java:5282)
    at java.awt.Container.processEvent(Container.java:1966)
    at java.awt.Component.dispatchEventImpl(Component.java:3984)
    at java.awt.Container.dispatchEventImpl(Container.java:2024)
    at java.awt.Component.dispatchEvent(Component.java:3819)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
    at java.awt.Container.dispatchEventImpl(Container.java:2010)
    at java.awt.Window.dispatchEventImpl(Window.java:1791)
    at java.awt.Component.dispatchEvent(Component.java:3819)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Thanks in advance for your help,
Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

SeparatorListBug.java (8K) Download Attachment

From forum: GlazedLists - User

re[4]: Using maps to suppliment data in a list

2008-10-02T06:59:50Z

Haven't profiled yet (it's been on the 'todo' list for 2 weeks now). For a list with 500 elements in it, a single change that effects all Observables in the lit took well over 500 ms to refresh - it was very noticible in the UI.

I'm not so much worried about the identity loop itself, rather the fact that if a given change causes lots of the oversvables to change, then OEL implementation results in individual change operations being sent into the pipeline. So the performance of downstream handlers is almost certainly the actual bottleneck, but the root cause is that those handlers are receiving individual events - instead of sorting the changed list once, for example, the sort is having to be performed O(n) times.

There isn't much that can be done about this with the Observable pattern as it is - I think this is more of a reflection that Observable isn't performant in list situations where you have a lot of changes going on (which I'm sure is why GL uses a different event publishing mechanism!). In our situation, the Function state is backed by an EventList, so we are able to get a group of changes. Sending those all as a single event would, I believe, have huge performance advantages over the simple OEL.

If I were going to try to come up with a simple solution, I would consider an enhanced form of OEL that has a elementsChanged(List<E> changes) method:

public void elementsChanged(List<E> listElements) {
this.updates.beginEvent();
// locate all indexes containing the given listElements
for (int i = 0, n = size(); i < n; i++) {
for (E listElement : listElements) { // <-- extra loop
if (listElement == get(i))
this.updates.elementUpdated(i, listElement);
}
}
this.updates.commitEvent();
}

Having that in OEL is a bit messy (we are really dealing with changes in state of the Function, not the downstream elements - the OEL approach feels like we are trying to push things in the wrong place in the pipeline), but it gives the idea.

The way I'm thinking about this is that there are several different classifications of Function objects. We have stateless, globally stateful and element stateful. When a non-stateless function changes state, notification need to be sent to the FunctionList that a refresh is needed. This assumes that the Function implementation is even capable of treating multiple state changes in an atomic way (which we can do by using an EventList to back our map).

I realize that this may be getting pretty specialized... But I'm hoping that I'm keeping the behavior abstracted enough for general use.

Here's one idea on an implementation:

Introduce a StatefulFunction interface that allows the Function to observe changes in Function state. AdvancedFunction almost has this capability (we could check identity of the before and after value. If they are different then we know for sure that the function state changed for that element. However, there is no guarantee that identity = no change - the state of the element itself could have changed.

Instead, I think we punt the requirement for determining whether a given element has changed up to the StatefulFunction itself.

So, we have (in rough pseudo-code):

class StatefulFunctionImpl{
public void registerFunctionChangeListener(FunctionChangeListener l){blah}

private void fireChangeNotificaiton(final List stateChanges){
for(FunctionChangeListener listener: listeners){
listener.functionStateChanged(Function f, new ChangeDeterminer(){
public boolean isElementChanged(E element){
return stateChangeCausedElementChanged(stateChanges, element);
}
});
}
}
}

The stateChangeCausedElementChanged() method is a private utility method specific to the Function (only a given Function implementation can tell for sure if it's internal state change caused a given element to change).

The FunctionList would receive functionStateChanged, then loop it's elements using the ChangeDeterminer as a callback to determine which indexes should be added to the updates list in the FunctionList event firing. Note that this would also be usable by other list implementations that work with Function objects...

Thoughts/comments?

- K

----------------------- Original Message -----------------------

From: "James Lemieux" <jplemieux@...>
To: users@...
Cc:
Date: Wed, 1 Oct 2008 16:42:45 -0700
Subject: Re: re[2]: Using maps to suppliment data in a list

Any time I've looked at the performance of ObservableElementList.elementChanged, it has always been plenty fast. For EventLists on the order of 10s of 1000s of elements I believe I saw timings between 16 and 32 milliseconds on my machine. How many elements does your ObservableElementList contain, and how many changes are you making simultaneously?

Did you profile the app, to determine the hotspot?

My guess is that the downstream ListEventListeners are probably taking much more of the total time than the tight identity loop in ObservableElementList.elementChanged()... in which case you may do better to use a TransactionList to batch up the changes into a larger update.....

James

On Wed, Oct 1, 2008 at 3:09 PM, Kevin Day <kevin@...> wrote:

OK - thanks. Option 1 is exactly the solution that we are working with for testing (although we use a simple Connector so we can maintain decoupling).

If we run into performance issues, I'll have to give some thought to option 2. The ObservableElementList may not be efficient if we are dealing with multiple simultaneous changes to the CompliationResults map. The compilation could be providing multiple updates to the EventList that backs the CompliationResultManager. Having ObservableElementList loop the entire list over and over again is not particularly efficient.

We actually ran into this when we had each of our elements in one list bound to a value holder. We'd change the value in the value holder, all of the elements in the list would fire their own property change events, and the ObservableElementList would grind things to a halt as it performed the O(n) individual event notifications on the pipeline.

This performance issue is what brought up my original question. I'll give it some thought - maybe there's a way to abstract this desired behavior somehow. I'm sure that providing data from an event aware map to a composite object should be a factorable concern...

- K

----------------------- Original Message -----------------------

From: "James Lemieux" <jplemieux@...>
To: users@...
Cc:
Date: Wed, 1 Oct 2008 14:20:08 -0700
Subject: Re: Using maps to suppliment data in a list

If you absolutely need to store this "supplemental data" in a Map, and the Map can change, then there are just 2 solutions I can concieve of:

1) If you can get a handle to an appropriate ObservableElementList in your pipeline, you could actually call elementChanged() manually (from within your CompilationResultsManager) and let it do all of this work for you....

2) Otherwise you can mimic some of the function of ObservableElementList yourself. i.e.:

The map within the "CompliationResultsManager" is updated, and immediately after the update the SourceFile(s) that were effected are then found (by identity, so it can be done quickly) in the appropriate EventList and set overtop of themselves.

e.g.:

SourceFile changed = ....

eventList.getReadWriteLock().writeLock().lock();
try {
// locate all indexes containing the given listElement
for (int i = 0, n = size(); i < n; i++) {
if (changed == eventList.get(i))
eventList.set(i, changed);

} finally {
eventList.getReadWriteLock().writeLock().unlock();
}

This code is very similar to ObservableElementList.elementChanged(...);

This code has no effect on the contents of the EventList, but DOES raise a ListEvent describing an update at index i so that downstream EventLists can react accordiingly. In fact, before ObservableElementList was written, this was the only way to force updates through a pipeline....

James

On Mon, Sep 29, 2008 at 3:18 PM, Kevin Day <kevin@...> wrote:

This may be one of those insane questions that just shouldn't be asked - but you never know... I'm also open to the idea that I may be asking the wrong question, and that there is a better way to attack the problem I describe below. Here's the question:

If we are using one EventList to inject information into the elements of another EventList (i.e. compositing objects together) via FunctionList, is there an effective way to manage updates in the pipeline, or do we have to step outside of the pipeline event notification mechanism and use ObservableElementList?

Here are the details behind the question:

We have an EventList of business objects. As part of our processing, we wind up with supplimental data associated with the business objects that we want to be able to display in a grid, or possibly even perform additional filtering/sorting/etc... with.

To make this concrete, imagine a compiler that has a list of files (SourceFile objects). The results of the compilation are stored in CompilationResults instances.

There are a number of ways to deal with this architecturaly - but right now the most desirable one is to have an external CompliationResultsManager that maintains a map between SourceFile objects (or really ANY sort of object that might be compilable) and the corresponding CompilationResults. Then we use a FunctionList to build a list of composite SourceFile/CompliationResults objects when and where we need them (i.e. for display in a grid). We would use a private SourceFileAndResults class or something along those lines to hold the composite.

GlazedLists makes this a piece of cake - with one little problem: It is possible (in fact likely) that the map backing the Function could change (e.g. we call myCompilationResultsMap.put(someSourceFile, newCompilationResults) ) - and we need to have some mechanism for sending change notifications for the effected list members.

If the Function was changing in a global sense (i.e. all of the composite objects in the list need to be updated), we could force the issue by just re-setting the same forwardFunction. But our situation is more surgical than that.

A single change to the map really only requires a few elements in the list to update. To make things more interesting, we are thinking about using an EventList along with syncEventListToMap() to manage the SourceFile->CompilationResults map. Ideally, changes to the map's event list would be reflected automatically in the main list pipeline.

And here's a potential solution, but one that makes me a bit uncomfortable... :

One option that we are considering is to place an ObservableElementList right before the FunctionList in the pipeline, then use a custom Connector object that fires changes in response to changes in the map (the keys to the map are the elements of the OversavableElementList). It would be nice to be able to have the Connector issue batches of changes in an efficient way (rather than submitting them one at a time)... If performance is an issue, I suppose that we could subclass ObesrvableElementList to come up with an elementChanged() method that accepts a list of changed elements.

That said, I'm concerned that the use of Observable here is stepping outside of the purpose of the event publisher. Is there any way to take advantage of the fact that we are using EventLists for both the map and the pipeline? Or am I worrying about the wrong thing? Do I need to create a relatedListener relationship between the two lists?

Is there a better way to deal with this kind of situation, or is there some other strategy that we might be missing?

Thanks much,

- K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: re[2]: Using maps to suppliment data in a list

2008-10-01T16:42:45Z

Any time I've looked at the performance of ObservableElementList.elementChanged, it has always been plenty fast. For EventLists on the order of 10s of 1000s of elements I believe I saw timings between 16 and 32 milliseconds on my machine. How many elements does your ObservableElementList contain, and how many changes are you making simultaneously?

Did you profile the app, to determine the hotspot?

My guess is that the downstream ListEventListeners are probably taking much more of the total time than the tight identity loop in ObservableElementList.elementChanged()... in which case you may do better to use a TransactionList to batch up the changes into a larger update.....

James

On Wed, Oct 1, 2008 at 3:09 PM, Kevin Day <kevin@...> wrote:

OK - thanks. Option 1 is exactly the solution that we are working with for testing (although we use a simple Connector so we can maintain decoupling).

If we run into performance issues, I'll have to give some thought to option 2. The ObservableElementList may not be efficient if we are dealing with multiple simultaneous changes to the CompliationResults map. The compilation could be providing multiple updates to the EventList that backs the CompliationResultManager. Having ObservableElementList loop the entire list over and over again is not particularly efficient.

We actually ran into this when we had each of our elements in one list bound to a value holder. We'd change the value in the value holder, all of the elements in the list would fire their own property change events, and the ObservableElementList would grind things to a halt as it performed the O(n) individual event notifications on the pipeline.

This performance issue is what brought up my original question. I'll give it some thought - maybe there's a way to abstract this desired behavior somehow. I'm sure that providing data from an event aware map to a composite object should be a factorable concern...

- K

----------------------- Original Message -----------------------

From: "James Lemieux" <jplemieux@...>
To: users@...
Cc:
Date: Wed, 1 Oct 2008 14:20:08 -0700
Subject: Re: Using maps to suppliment data in a list

If you absolutely need to store this "supplemental data" in a Map, and the Map can change, then there are just 2 solutions I can concieve of:

1) If you can get a handle to an appropriate ObservableElementList in your pipeline, you could actually call elementChanged() manually (from within your CompilationResultsManager) and let it do all of this work for you....

2) Otherwise you can mimic some of the function of ObservableElementList yourself. i.e.:

The map within the "CompliationResultsManager" is updated, and immediately after the update the SourceFile(s) that were effected are then found (by identity, so it can be done quickly) in the appropriate EventList and set overtop of themselves.

e.g.:

SourceFile changed = ....

eventList.getReadWriteLock().writeLock().lock();
try {
// locate all indexes containing the given listElement
for (int i = 0, n = size(); i < n; i++) {
if (changed == eventList.get(i))
eventList.set(i, changed);

} finally {
eventList.getReadWriteLock().writeLock().unlock();
}

This code is very similar to ObservableElementList.elementChanged(...);

This code has no effect on the contents of the EventList, but DOES raise a ListEvent describing an update at index i so that downstream EventLists can react accordiingly. In fact, before ObservableElementList was written, this was the only way to force updates through a pipeline....

James

On Mon, Sep 29, 2008 at 3:18 PM, Kevin Day <kevin@...> wrote:

This may be one of those insane questions that just shouldn't be asked - but you never know... I'm also open to the idea that I may be asking the wrong question, and that there is a better way to attack the problem I describe below. Here's the question:

If we are using one EventList to inject information into the elements of another EventList (i.e. compositing objects together) via FunctionList, is there an effective way to manage updates in the pipeline, or do we have to step outside of the pipeline event notification mechanism and use ObservableElementList?

Here are the details behind the question:

We have an EventList of business objects. As part of our processing, we wind up with supplimental data associated with the business objects that we want to be able to display in a grid, or possibly even perform additional filtering/sorting/etc... with.

To make this concrete, imagine a compiler that has a list of files (SourceFile objects). The results of the compilation are stored in CompilationResults instances.

There are a number of ways to deal with this architecturaly - but right now the most desirable one is to have an external CompliationResultsManager that maintains a map between SourceFile objects (or really ANY sort of object that might be compilable) and the corresponding CompilationResults. Then we use a FunctionList to build a list of composite SourceFile/CompliationResults objects when and where we need them (i.e. for display in a grid). We would use a private SourceFileAndResults class or something along those lines to hold the composite.

GlazedLists makes this a piece of cake - with one little problem: It is possible (in fact likely) that the map backing the Function could change (e.g. we call myCompilationResultsMap.put(someSourceFile, newCompilationResults) ) - and we need to have some mechanism for sending change notifications for the effected list members.

If the Function was changing in a global sense (i.e. all of the composite objects in the list need to be updated), we could force the issue by just re-setting the same forwardFunction. But our situation is more surgical than that.

A single change to the map really only requires a few elements in the list to update. To make things more interesting, we are thinking about using an EventList along with syncEventListToMap() to manage the SourceFile->CompilationResults map. Ideally, changes to the map's event list would be reflected automatically in the main list pipeline.

And here's a potential solution, but one that makes me a bit uncomfortable... :

One option that we are considering is to place an ObservableElementList right before the FunctionList in the pipeline, then use a custom Connector object that fires changes in response to changes in the map (the keys to the map are the elements of the OversavableElementList). It would be nice to be able to have the Connector issue batches of changes in an efficient way (rather than submitting them one at a time)... If performance is an issue, I suppose that we could subclass ObesrvableElementList to come up with an elementChanged() method that accepts a list of changed elements.

That said, I'm concerned that the use of Observable here is stepping outside of the purpose of the event publisher. Is there any way to take advantage of the fact that we are using EventLists for both the map and the pipeline? Or am I worrying about the wrong thing? Do I need to create a relatedListener relationship between the two lists?

Is there a better way to deal with this kind of situation, or is there some other strategy that we might be missing?

Thanks much,

- K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

re[2]: Using maps to suppliment data in a list

2008-10-01T15:09:34Z

OK - thanks. Option 1 is exactly the solution that we are working with for testing (although we use a simple Connector so we can maintain decoupling).

If we run into performance issues, I'll have to give some thought to option 2. The ObservableElementList may not be efficient if we are dealing with multiple simultaneous changes to the CompliationResults map. The compilation could be providing multiple updates to the EventList that backs the CompliationResultManager. Having ObservableElementList loop the entire list over and over again is not particularly efficient.

We actually ran into this when we had each of our elements in one list bound to a value holder. We'd change the value in the value holder, all of the elements in the list would fire their own property change events, and the ObservableElementList would grind things to a halt as it performed the O(n) individual event notifications on the pipeline.

This performance issue is what brought up my original question. I'll give it some thought - maybe there's a way to abstract this desired behavior somehow. I'm sure that providing data from an event aware map to a composite object should be a factorable concern...

- K

----------------------- Original Message -----------------------

From: "James Lemieux" <jplemieux@...>
To: users@...
Cc:
Date: Wed, 1 Oct 2008 14:20:08 -0700
Subject: Re: Using maps to suppliment data in a list

If you absolutely need to store this "supplemental data" in a Map, and the Map can change, then there are just 2 solutions I can concieve of:

1) If you can get a handle to an appropriate ObservableElementList in your pipeline, you could actually call elementChanged() manually (from within your CompilationResultsManager) and let it do all of this work for you....

2) Otherwise you can mimic some of the function of ObservableElementList yourself. i.e.:

The map within the "CompliationResultsManager" is updated, and immediately after the update the SourceFile(s) that were effected are then found (by identity, so it can be done quickly) in the appropriate EventList and set overtop of themselves.

e.g.:

SourceFile changed = ....

eventList.getReadWriteLock().writeLock().lock();
try {
// locate all indexes containing the given listElement
for (int i = 0, n = size(); i < n; i++) {
if (changed == eventList.get(i))
eventList.set(i, changed);

} finally {
eventList.getReadWriteLock().writeLock().unlock();
}

This code is very similar to ObservableElementList.elementChanged(...);

This code has no effect on the contents of the EventList, but DOES raise a ListEvent describing an update at index i so that downstream EventLists can react accordiingly. In fact, before ObservableElementList was written, this was the only way to force updates through a pipeline....

James

On Mon, Sep 29, 2008 at 3:18 PM, Kevin Day <kevin@...> wrote:

This may be one of those insane questions that just shouldn't be asked - but you never know... I'm also open to the idea that I may be asking the wrong question, and that there is a better way to attack the problem I describe below. Here's the question:

If we are using one EventList to inject information into the elements of another EventList (i.e. compositing objects together) via FunctionList, is there an effective way to manage updates in the pipeline, or do we have to step outside of the pipeline event notification mechanism and use ObservableElementList?

Here are the details behind the question:

We have an EventList of business objects. As part of our processing, we wind up with supplimental data associated with the business objects that we want to be able to display in a grid, or possibly even perform additional filtering/sorting/etc... with.

To make this concrete, imagine a compiler that has a list of files (SourceFile objects). The results of the compilation are stored in CompilationResults instances.

There are a number of ways to deal with this architecturaly - but right now the most desirable one is to have an external CompliationResultsManager that maintains a map between SourceFile objects (or really ANY sort of object that might be compilable) and the corresponding CompilationResults. Then we use a FunctionList to build a list of composite SourceFile/CompliationResults objects when and where we need them (i.e. for display in a grid). We would use a private SourceFileAndResults class or something along those lines to hold the composite.

GlazedLists makes this a piece of cake - with one little problem: It is possible (in fact likely) that the map backing the Function could change (e.g. we call myCompilationResultsMap.put(someSourceFile, newCompilationResults) ) - and we need to have some mechanism for sending change notifications for the effected list members.

If the Function was changing in a global sense (i.e. all of the composite objects in the list need to be updated), we could force the issue by just re-setting the same forwardFunction. But our situation is more surgical than that.

A single change to the map really only requires a few elements in the list to update. To make things more interesting, we are thinking about using an EventList along with syncEventListToMap() to manage the SourceFile->CompilationResults map. Ideally, changes to the map's event list would be reflected automatically in the main list pipeline.

And here's a potential solution, but one that makes me a bit uncomfortable... :

One option that we are considering is to place an ObservableElementList right before the FunctionList in the pipeline, then use a custom Connector object that fires changes in response to changes in the map (the keys to the map are the elements of the OversavableElementList). It would be nice to be able to have the Connector issue batches of changes in an efficient way (rather than submitting them one at a time)... If performance is an issue, I suppose that we could subclass ObesrvableElementList to come up with an elementChanged() method that accepts a list of changed elements.

That said, I'm concerned that the use of Observable here is stepping outside of the purpose of the event publisher. Is there any way to take advantage of the fact that we are using EventLists for both the map and the pipeline? Or am I worrying about the wrong thing? Do I need to create a relatedListener relationship between the two lists?

Is there a better way to deal with this kind of situation, or is there some other strategy that we might be missing?

Thanks much,

- K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: Using maps to suppliment data in a list

2008-10-01T14:20:08Z

If you absolutely need to store this "supplemental data" in a Map, and the Map can change, then there are just 2 solutions I can concieve of:

1) If you can get a handle to an appropriate ObservableElementList in your pipeline, you could actually call elementChanged() manually (from within your CompilationResultsManager) and let it do all of this work for you....

2) Otherwise you can mimic some of the function of ObservableElementList yourself. i.e.:

The map within the "CompliationResultsManager" is updated, and immediately after the update the SourceFile(s) that were effected are then found (by identity, so it can be done quickly) in the appropriate EventList and set overtop of themselves.

e.g.:

SourceFile changed = ....

eventList.getReadWriteLock().writeLock().lock();
try {
      // locate all indexes containing the given listElement
      for (int i = 0, n = size(); i < n; i++) {
         if (changed == eventList.get(i))
            eventList.set(i, changed);

} finally {
   eventList.getReadWriteLock().writeLock().unlock();
}

This code is very similar to ObservableElementList.elementChanged(...);

This code has no effect on the contents of the EventList, but DOES raise a ListEvent describing an update at index i so that downstream EventLists can react accordiingly. In fact, before ObservableElementList was written, this was the only way to force updates through a pipeline....

James

On Mon, Sep 29, 2008 at 3:18 PM, Kevin Day <kevin@...> wrote:

This may be one of those insane questions that just shouldn't be asked - but you never know... I'm also open to the idea that I may be asking the wrong question, and that there is a better way to attack the problem I describe below. Here's the question:

If we are using one EventList to inject information into the elements of another EventList (i.e. compositing objects together) via FunctionList, is there an effective way to manage updates in the pipeline, or do we have to step outside of the pipeline event notification mechanism and use ObservableElementList?

Here are the details behind the question:

We have an EventList of business objects. As part of our processing, we wind up with supplimental data associated with the business objects that we want to be able to display in a grid, or possibly even perform additional filtering/sorting/etc... with.

To make this concrete, imagine a compiler that has a list of files (SourceFile objects). The results of the compilation are stored in CompilationResults instances.

There are a number of ways to deal with this architecturaly - but right now the most desirable one is to have an external CompliationResultsManager that maintains a map between SourceFile objects (or really ANY sort of object that might be compilable) and the corresponding CompilationResults. Then we use a FunctionList to build a list of composite SourceFile/CompliationResults objects when and where we need them (i.e. for display in a grid). We would use a private SourceFileAndResults class or something along those lines to hold the composite.

GlazedLists makes this a piece of cake - with one little problem: It is possible (in fact likely) that the map backing the Function could change (e.g. we call myCompilationResultsMap.put(someSourceFile, newCompilationResults) ) - and we need to have some mechanism for sending change notifications for the effected list members.

If the Function was changing in a global sense (i.e. all of the composite objects in the list need to be updated), we could force the issue by just re-setting the same forwardFunction. But our situation is more surgical than that.

A single change to the map really only requires a few elements in the list to update. To make things more interesting, we are thinking about using an EventList along with syncEventListToMap() to manage the SourceFile->CompilationResults map. Ideally, changes to the map's event list would be reflected automatically in the main list pipeline.

And here's a potential solution, but one that makes me a bit uncomfortable... :

One option that we are considering is to place an ObservableElementList right before the FunctionList in the pipeline, then use a custom Connector object that fires changes in response to changes in the map (the keys to the map are the elements of the OversavableElementList). It would be nice to be able to have the Connector issue batches of changes in an efficient way (rather than submitting them one at a time)... If performance is an issue, I suppose that we could subclass ObesrvableElementList to come up with an elementChanged() method that accepts a list of changed elements.

That said, I'm concerned that the use of Observable here is stepping outside of the purpose of the event publisher. Is there any way to take advantage of the fact that we are using EventLists for both the map and the pipeline? Or am I worrying about the wrong thing? Do I need to create a relatedListener relationship between the two lists?

Is there a better way to deal with this kind of situation, or is there some other strategy that we might be missing?

Thanks much,

- K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: re[2]: Debugging Listener Cycles

2008-10-01T10:53:59Z

A few explanations to some of the open questions / comments in this Thread:

1) All EventLists in a pipeline *must* share the same read/write locks.... that assumption is guaranteed to remain stable forever.

2) Sam, demonstrated a nice exception to my previously stated rule: stateless ListEventListeners don't need to be guarded with locks during creation or addition to the pipeline. Good Point Sam.

3) Any STATEFUL ListEventListener (nearly all TransformedLists are good examples of STATEFUL ListEventListeners) needs to prevent modification of the pipeline's data during its initialization and registration with the pipeline. In other words:

{
   // 1. initialize my internal state from the source EventList

   // 2. start listening to changes in the source EventList
}

needs to be an atomic operation, guarded by AT LEAST the read lock (the write lock would work too, but would be overkill since we only expect read operations on the pipeline during 1.).

4. To make something clear: when a ListEvent is fired through a pipeline, it is effectively operating on a copy of the data structure that contains all ListEventListeners. (In practice, we use copy-on-write semantics to guarantee this, not copy-on-read, since the number of reads of the data structure > number of writes) This removes any ambiguity about which ListEventListeners should receive the ListEvent. Changes to the pipeline during the firing of a ListEvent will not be see the ListEvent. They will see subsequent ListEvents.

5. Sam made a nice suggestion with TransformedListsFactory. It would remove much of the "intellectual weight" to this kind of problem. There's only one major stroke against such a class. One of the design considerations permeating all of GL is that we give our API users the tools to be "thread-safe" (read / write locks), but we don't use those tools on their behalf. (In practice there ARE a few places in the bowels of GL where we do acquire locks because users can't/shouldn't get to those areas, so we're not perfect on this philosophy). We call this design "thread-ready" but not "thread-safe". The reasons for this design are simple:

   a) some apps don't need locking at all, and would be penalized unnecessarily (i.e. all operations on the pipeline are from a single thread)

   b) the more a library acquires public locks, the more you increase the potential for deadlock. There is no automatic scheme for resolving these problems... so instead we pass the torch to our API users and say "you probably know much better than we ever could if and when you need to lock things"

So, with 5. in mind, is it correct to lock the pipeline on behalf of the API user during the constructor of a TransformedList? Where are Socrates and Plato when you need them most?

James

On Wed, Oct 1, 2008 at 9:05 AM, Sam Berlin <sberlin@...> wrote:

It would seem like there should be a TransformedListsFactory that has
create methods for all transformed list subclasses and locks the
source list while creating the sublist, as well as a utility method
that adds listeners under the source list's lock (assuming that's
necessary -- I still don't completely understand why it is).

Sam

On Wed, Oct 1, 2008 at 11:40 AM, Kevin Day <kevin@...> wrote:
> The place I've run into problems with only grabbing a read lock when adding
> listeners is when you start bridging threads. For example, the list that
> moves events over to the Swing EDT has some extremely funky logic in it to
> ensure that calls are dispatched in an orderly fashion - even if you are
> adding a listener when there are already events in the queue (yes - it's
> really, really nasty - I don't understand the code completely, but I spent
> enough time spelunking during a debugging session awhile back that I
> appreciate the complexity and the reason for it). When it does this, it
> dispatches an event onto the EDT and waits for that event to complete. That
> event, in turn, can wind up having to grab a write lock on the list
> pipeline. This creates a potential race condition if you are just grabbing
> read locks when you add listeners.
>
> When we implemented our PluggableEventList, we found that if we only grabbed
> a read-lock before adding listeners that we dead-locked sometimes b/c of the
> EDT proxying behavior. Grabbing a write lock is defensive in this regard.
>
> I think the way to explain it is that the readwrite lock is protecting a
> *lot* more than just the contents of the list. The lock is *actually*
> protecting the list event publisher state as well. And changes to the
> listener lists in the list event publisher are changing state, and therefore
> need to be write locked.
>
> I hope that helps!
>
> - K
>
> ----------------------- Original Message -----------------------
>
> From: "Sam Berlin" <sberlin@...>
> To: users@...
> Cc:
> Date: Wed, 1 Oct 2008 10:43:33 -0400
> Subject: Re: Debugging Listener Cycles
>
> That was going to be my next question. Still, I can see somewhat how
> it's necessary for something like creating FilterList, since the
> constructor is:
>
> {
> super(source);
>
> // build a list of what is filtered and what's not
> flagList.addBlack(0, source.size());
>
> // listen for changes to the source list
> source.addListEventListener(this);
> }
>
> You'd want to make sure the list is blocked from changes during that
> interval, making sure the listener is added while the source doesn't
> change.
>
> But, I don't understand why it's necessary when doing something just like:
>
> list.addListEventListener(new ListEventListener() {
> public void listChanged(ListEvent changes) {
> myComponent.setText(changes.getSourceList().size());
> }
> });
>
> That doesn't need any atomically-stable state on the list, and looking
> at what happens when you call addListEventListener, it goes something
> like this:
>
> EventList.addListEventListener ->
> ListEventAssembler.addListEventListener ->
> AssemblerHelper.PublisherAdapter.addListEventListener ->
> SequenceDependenciesEventPublisher.addListener -> {
> updateEventListeners, createSubjectsAndListeners }
>
> At the point when it really starts to modify state, the methods
> themselves are synchronized. That is,
> ListEventAssembler.addListEventListener is synchronized, and
> SequenceDependenciesEventPublisher.addListener is also synchronized.
>
> So I guess I'm a little confused about what's actually going on.
>
> Thanks,
> Sam
>
> On Wed, Oct 1, 2008 at 10:30 AM, Jeremy Ford <caius1@...> wrote:
>> As a follow up, why would you use a read lock vs a write lock when adding
>> listeners to a list?
>>
>>> Date: Tue, 30 Sep 2008 17:30:17 -0700
>>> From: kevin@...
>>> To: users@...
>>> Subject: re: Debugging Listener Cycles
>>>
>>> Just a guess, but are you grabbing a read lock on the list prior to
>>> adding
>>> the thread safe wrapper? how about prior to adding listeners?
>>>
>>> At minimum, I think that describing your locking calls surrounding each
>>> of
>>> these operations will be useful in determining what might be going on.
>>>
>>> - K
>>>
>>> -- --------------------- Original Message -----------------------
>>>
>>> From: "Sam Berlin" <sberlin@...>
>>> To: users@...
>>> Cc:
>>> Date: Tue, 30 Sep 2008 19:55:26 -0400
>>> Subject: Debugging Listener Cycles
>>>
>>> Hi All,
>>>
>>> I've got a strange situation where some race condition (probably in
>>> our code, it's a guess based on it happening sometimes & not others)
>>> appears to be triggering an IllegalStateException within GlazedLists,
>>> the message being, "Listener cycle detected". Then there's a bunch of
>>> []'s and arrows pointing to numbers. I'm having a very hard time
>>> debugging the cause, because I'm not really sure what's going on.
>>>
>>> Our setup is like this:
>>>
>>> One master CompositeList. Many members of that list (created with
>>> CompositeList.createMemberList and added to it appropriately). Each
>>> member is then wrapped in a ThreadSafeList and then lazily (on the EDT
>>> thread) wrapped in a SwingThreadProxyEventList. The CompositeList is
>>> also wrapped in a ThreadSafeList, and that ThreadSafeList is wrapped
>>> in a UniqueList. A SwingThreadProxyEventList is lazily created for
>>> that UniqueList. Listeners are added to the member's ThreadSafeList
>>> and the STPEL. Listeners are also added to the CompositeList's STPEL
>>> wrapper over the UniqueList.
>>>
>>> What triggers the exception, sometimes, is adding a ThreadSafeList
>>> wrapper over a member list. Other times it's adding a listener to the
>>> member's STPEL wrapper.
>>>
>>> These exceptions all started happeni ng only after CompositeList was
>>> introduced -- before that, all member lists were created with new
>>> BasicEventList instead of CompositeList.createMemberList. Upon
>>> switching to CompositeList, the listener cycle now occasionally starts
>>> screaming.
>>>
>>> Any suggestions for how to debug or fix this?
>>>
>>> FWIW, the reason for this approach is: We have essentially a Map<Foo,
>>> EventList<FooItem>>. Each Foo can have many items associated with it.
>>> Various parts of the program interact with the individual FooItem
>>> lists, some even create their own EventList<Foo>, listening for new
>>> Foo's being added from other sections. The CompositeList is because
>>> we want a separate area that lists the sum-total of FooItems within
>>> each EventList<FooItem>, stripping out the uniques.
>>>
>>> Thanks very much in ad vance,
>>> Sam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ________________________________
>> See how Windows Mobile brings your life together—at home, work, or on the
>> go. See Now
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@... For
> additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User

Re: re[2]: Debugging Listener Cycles

2008-10-01T09:05:18Z

It would seem like there should be a TransformedListsFactory that has
create methods for all transformed list subclasses and locks the
source list while creating the sublist, as well as a utility method
that adds listeners under the source list's lock (assuming that's
necessary -- I still don't completely understand why it is).

Sam

On Wed, Oct 1, 2008 at 11:40 AM, Kevin Day <kevin@...> wrote:

> The place I've run into problems with only grabbing a read lock when adding
> listeners is when you start bridging threads. For example, the list that
> moves events over to the Swing EDT has some extremely funky logic in it to
> ensure that calls are dispatched in an orderly fashion - even if you are
> adding a listener when there are already events in the queue (yes - it's
> really, really nasty - I don't understand the code completely, but I spent
> enough time spelunking during a debugging session awhile back that I
> appreciate the complexity and the reason for it). When it does this, it
> dispatches an event onto the EDT and waits for that event to complete. That
> event, in turn, can wind up having to grab a write lock on the list
> pipeline. This creates a potential race condition if you are just grabbing
> read locks when you add listeners.
>
> When we implemented our PluggableEventList, we found that if we only grabbed
> a read-lock before adding listeners that we dead-locked sometimes b/c of the
> EDT proxying behavior. Grabbing a write lock is defensive in this regard.
>
> I think the way to explain it is that the readwrite lock is protecting a
> *lot* more than just the contents of the list. The lock is *actually*
> protecting the list event publisher state as well. And changes to the
> listener lists in the list event publisher are changing state, and therefore
> need to be write locked.
>
> I hope that helps!
>
> - K
>
> ----------------------- Original Message -----------------------
>
> From: "Sam Berlin" <sberlin@...>
> To: users@...
> Cc:
> Date: Wed, 1 Oct 2008 10:43:33 -0400
> Subject: Re: Debugging Listener Cycles
>
> That was going to be my next question. Still, I can see somewhat how
> it's necessary for something like creating FilterList, since the
> constructor is:
>
> {
> super(source);
>
> // build a list of what is filtered and what's not
> flagList.addBlack(0, source.size());
>
> // listen for changes to the source list
> source.addListEventListener(this);
> }
>
> You'd want to make sure the list is blocked from changes during that
> interval, making sure the listener is added while the source doesn't
> change.
>
> But, I don't understand why it's necessary when doing something just like:
>
> list.addListEventListener(new ListEventListener() {
> public void listChanged(ListEvent changes) {
> myComponent.setText(changes.getSourceList().size());
> }
> });
>
> That doesn't need any atomically-stable state on the list, and looking
> at what happens when you call addListEventListener, it goes something
> like this:
>
> EventList.addListEventListener ->
> ListEventAssembler.addListEventListener ->
> AssemblerHelper.PublisherAdapter.addListEventListener ->
> SequenceDependenciesEventPublisher.addListener -> {
> updateEventListeners, createSubjectsAndListeners }
>
> At the point when it really starts to modify state, the methods
> themselves are synchronized. That is,
> ListEventAssembler.addListEventListener is synchronized, and
> SequenceDependenciesEventPublisher.addListener is also synchronized.
>
> So I guess I'm a little confused about what's actually going on.
>
> Thanks,
> Sam
>
> On Wed, Oct 1, 2008 at 10:30 AM, Jeremy Ford <caius1@...> wrote:
>> As a follow up, why would you use a read lock vs a write lock when adding
>> listeners to a list?
>>
>>> Date: Tue, 30 Sep 2008 17:30:17 -0700
>>> From: kevin@...
>>> To: users@...
>>> Subject: re: Debugging Listener Cycles
>>>
>>> Just a guess, but are you grabbing a read lock on the list prior to
>>> adding
>>> the thread safe wrapper? how about prior to adding listeners?
>>>
>>> At minimum, I think that describing your locking calls surrounding each
>>> of
>>> these operations will be useful in determining what might be going on.
>>>
>>> - K
>>>
>>> -- --------------------- Original Message -----------------------
>>>
>>> From: "Sam Berlin" <sberlin@...>
>>> To: users@...
>>> Cc:
>>> Date: Tue, 30 Sep 2008 19:55:26 -0400
>>> Subject: Debugging Listener Cycles
>>>
>>> Hi All,
>>>
>>> I've got a strange situation where some race condition (probably in
>>> our code, it's a guess based on it happening sometimes & not others)
>>> appears to be triggering an IllegalStateException within GlazedLists,
>>> the message being, "Listener cycle detected". Then there's a bunch of
>>> []'s and arrows pointing to numbers. I'm having a very hard time
>>> debugging the cause, because I'm not really sure what's going on.
>>>
>>> Our setup is like this:
>>>
>>> One master CompositeList. Many members of that list (created with
>>> CompositeList.createMemberList and added to it appropriately). Each
>>> member is then wrapped in a ThreadSafeList and then lazily (on the EDT
>>> thread) wrapped in a SwingThreadProxyEventList. The CompositeList is
>>> also wrapped in a ThreadSafeList, and that ThreadSafeList is wrapped
>>> in a UniqueList. A SwingThreadProxyEventList is lazily created for
>>> that UniqueList. Listeners are added to the member's ThreadSafeList
>>> and the STPEL. Listeners are also added to the CompositeList's STPEL
>>> wrapper over the UniqueList.
>>>
>>> What triggers the exception, sometimes, is adding a ThreadSafeList
>>> wrapper over a member list. Other times it's adding a listener to the
>>> member's STPEL wrapper.
>>>
>>> These exceptions all started happeni ng only after CompositeList was
>>> introduced -- before that, all member lists were created with new
>>> BasicEventList instead of CompositeList.createMemberList. Upon
>>> switching to CompositeList, the listener cycle now occasionally starts
>>> screaming.
>>>
>>> Any suggestions for how to debug or fix this?
>>>
>>> FWIW, the reason for this approach is: We have essentially a Map<Foo,
>>> EventList<FooItem>>. Each Foo can have many items associated with it.
>>> Various parts of the program interact with the individual FooItem
>>> lists, some even create their own EventList<Foo>, listening for new
>>> Foo's being added from other sections. The CompositeList is because
>>> we want a separate area that lists the sum-total of FooItems within
>>> each EventList<FooItem>, stripping out the uniques.
>>>
>>> Thanks very much in ad vance,
>>> Sam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ________________________________
>> See how Windows Mobile brings your life together—at home, work, or on the
>> go. See Now
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@... For
> additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

From forum: GlazedLists - User