Hello!
I have faced with a problem of concurrent modification of Filter that leads
to exception throwing:
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)
at java.util.AbstractList$Itr.next(AbstractList.java:420)
at
org.geotools.filter.LogicFilterImpl.contains(LogicFilterImpl.java:165)
at
org.geotools.data.FilteringFeatureReader.hasNext(FilteringFeatureReader.java
:121)
at
org.geotools.data.ReTypeFeatureReader.hasNext(ReTypeFeatureReader.java:149)
at
org.geotools.data.DefaultFeatureResults.getCount(DefaultFeatureResults.java:
242)
at
org.geotools.data.store.DataFeatureCollection.size(DataFeatureCollection.jav
a:257)
at
org.geotools.data.store.DataFeatureCollection.accepts(DataFeatureCollection.
java:582)
The thread where the exception is thrown is processing FeatureVisitor passed
to FeatureCollection while another thread tries to call Filter.and(Filter
filter) that modifies the LogicFilterImpl.
This use case is coming from UDIG.
Shouldn't all the Filter objects be immutable? (Just a quick mind). Or what
does the Filter design say about Filter modifications and multi-threading
issues?
For UDIG team: for the time being I suggest to revisit the Filter
construction in methods MapImpl.select(*) to make them thread-safe by
creating a new instance each time .
Vitali.
-------------------------------------------------------------------------
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
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
