Hi Sunburned,
If I understand the bug in question, it is not easy to reproduce. It has
been my experience that you can't fix bugs unless you can reproduce them,
otherwise you can't know when they are fixed. All you can do otherwise is
to apply a lot of preventative measures that may improve the situation, or
it might even make it worse. Does anyone have a scenario that will cause
the bug to reproduce often enough to meet this requirement? If not, the
prudent course IMHO is to wait until such a case occurs.
regards,
Larry
On 1/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
I'm afraid I have to again correct my observations on Bug #1487099. I was
looking at the LayerManager class this morning and realized that the method
causing Pedro's ConcurrentModificationException hasn't yet been fixed by
creating a copy of the LayerListener collection. This fix was applied by Jon
Aquino to some other methods.
After chewing over the problem for a while last night I realize that
creating a copy of the LayerListener collection stored by the LayerManager
class isn't a totally "thread safe" solution to this problem. It does
eliminate the possibility of the ConcurrentModificationExceptions but I
think it would allow a LayerListener to be sent an event when it should not
receive them.
Let me give a quick example of this scenario.
I did a little work on a Data Source Catalog that allows the user to
associate Layers and DataSources. As part of this extension for OpenJUMP I
might have created a LayerListener that presents a dialog box to the user
when a layer is deleted, or removed from the LayerManager. This dialog box
would ask the user if they would also like to delete any DataSources
associated with the Layer. Similarly, the LayerListener might present a
dialog box when a Layer is added to the LayerManager asking the user if they
would like to associate the new Layer with a DataSource.
These 2 dialog boxes could get a little irritating, so I might include an
option that allows the user to turn it "off". This could easily be done by
removing the LayerListener from the LayerManager. This might also be done
programatically by other plug-ins that add or remove layers as part of their
operation.
Here is the problem.
The user performs some action that will cause a Layer to be added or
removed from the LayerManager. When this happens the LayerManager creates a
copy of the LayerListeners collection and begins to iterate over it calling
the appropriate methods of the LayerListeners in a new thread.
The user then performs another action while this thread is running that
causes one of the LayerListeners to be removed from the LayerManager's
collection of LayerListeners. This LayerListener has not been removed from
the copy of the LayerListener collection that is being manipulated by the
thread created previously when a Layer was added or removed. That means the
LayerManager will pass the LayerChanged event to a LayerListener that is no
longer supposed to receive this event because it is present in the copied
collection. (It is no longer present in the original LayerListener
collection.)
I know this would be a rare occurence, but it is possible. I think it
leaves the potential for some hard-to-locate bugs in the future. I believe
this problem can be solved in a thread safe way by restricting access the
the LayerListeners collection with synchronized methods.
Like I said, I'm no expert at threads, and If I'm not understanding this
correctly I'd really appreciate some help!
If my theory about this situation isn't all messed up I'll get started on
the "thread safe" solution for the next release of OpenJUMP. I'll work with
Vivid Solutions to get it incorporated into JUMP as well.
Thanks for any input on this situation.
The Sunburned Surveyor
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
