Hi Vitali,
thank you for sharing your experiences.
UDig is far from being a perfect GIS
program, but it's based on some nice ideas
and definitely has potential. And I love
the concept of being an open source
project, making it possible for everybody
to contribute to make uDig better.
You have some valuable changes (taking the
render requests into a separate thread and
joining them definitely seems valuable to
me, what do the others think?). I would
love to see a contribution heading into
this direction, but know myself, that it
is hard to isolate the changes for a
special issue inside code, which grew over
years. I am willing to help, if there are
any questions.
Are you willing to share your solution? Do
the others also think, that this goes into
a good direction? What would be needed for
such a design change (proposal, ...)?
Hendrik
---
Hello.
Rendering engine in UDIG is
overcomplicated and has several design
defects. Hacks and workarounds won't
help (based on my 10 years exp.
with UDIG codebase). Some time ago I
solved this problem for our UDIG-based
projects (still net.refractions.udig
based) by rewriting some code around
IRenderer, IRenderExecutor, RenderManager
etc.
Briefly.
Configuration of renderers is
re-evaluated too often and it may happen
in any thread. Because of some complexity
in code (EMF + multithreading
+ overcomplicated design) during last 10
years noone resolved this
properly.
I implemented new render manager that
lives in MapImpl when MapEditor is
opened. It has 1 special thread for
events. Events are:
- refresh on layer
- refresh of the whole map
- layer added
- layer removed
- style changed
- layer order is changed
- etc.
All events that are causing rendering are
coming to the queue and this
special thread handles this queue. It
does it efficiently: every
iteration takes all events from the queue
and compresses them into one
global event that causes re-evaluating
renderers configuration and
starts rendering jobs.
Because renderers configuration
reevaluation is in special thread
working with queue of events coming from
different threads -
synchronization problem you are discussing
- is solved. As many other
related problems.
Vitali.
On 04/02/2016 12:06, Peilke, Hendrik
wrote:
Hi,
I went a while now with Emilys solution
and the exception still occurred
sometimes. I am running tests now with a
synchronized-block around every call to
getLayers() and every reference to the
layers-set (a lot of them had them
already). Maybe this helps avoid the
exception in future.
Hendrik
----
Yes, I will test for a while and if it
works I will make a pull request.
Thanks,
Emily
On 11/16/2015 1:12 AM, Frank Gasdorf
wrote:
Thank you folks
for this discussion and sharing your
thoughts.
Emily, If the solution works, please
create a pull request against
master for this. if your changes are
against 1.5.x I can help merging
it into master afterwards.
Best regards
- Frank
2015-11-16 9:37 GMT+01:00 Peilke, Hendrik
<hendrik.peilke@xxxxxxxxx
<mailto:hendrik.peilke@xxxxxxxxx>>:
Hi Emily,
your solution looks good. Thanks for
sharing.
The original solution probably
didn't work out, because the sorted
order is not persisted inside the
layerToMetricsFactoryMap, which is
assumed by the other methods
accessing it after createConfiguration
was called (best fit needs to be
first in list).
I will give your solution a try and
see how it works. In case of
success: Are you going to commit
that to uDig or should I put it on
my list of changes I want to commit?
Hendrik
-----Ursprüngliche Nachricht-----
Von: udig-dev-bounces@xxxxxxxxxxxxxxxx
<mailto:udig-dev-bounces@xxxxxxxxxxxxxxxx>
[mailto:udig-dev-bounces@xxxxxxxxxxxxxxxx
<mailto:udig-dev-bounces@xxxxxxxxxxxxxxxx>]
Im Auftrag von Emily Gouge
Gesendet: Samstag, 14. November 2015
01:52
An: uDig project developer
discussion
Betreff: Re: [udig-dev]
RendererCreatorImpl and
ConcurrentModificationException
Thanks for the info Hendrik. Good
to know I am not the only one
with that issue.
It seems my simple solution didn't
work out so well for me. When I
tried to create a new array list the
rendering stopped working all
together. I ended up using a
synchronized block, but I just put it
around the sorting call to try to
reduce the performance drawbacks.
We'll see how well that works.
Thanks,
Emily
On 13/11/2015 1:46 AM, Peilke,
Hendrik wrote:
> Hi,
>
> I had this error too in uDig
1.4.0. with Java 7. What I did
inside RenderManagerDynamic.refresh
is synchronize the access to the
RendererCreatorImpl like this:
>
>
synchronized(getRendererCreator())
> {
>
> getRendererCreator().reset();
>
validateRendererConfiguration();
> selectionLayer =
getRendererCreator()
> .findSelectionLayer(layer);
> }
>
> Maybe the synchronize block is
too big and maybe it would be
better inside the RendererCreator.I
didn't test any further, because
that solved the problem for me and
we had little time to integrate
uDig into our product. The solution
has the downside of slowing
down the rendering a little, when
receiving multiple calls (e.g.
from program code and ui).
>
> Hendrik
>
> -----Ursprüngliche
Nachricht-----
> Von:
udig-dev-bounces@xxxxxxxxxxxxxxxx
<mailto:udig-dev-bounces@xxxxxxxxxxxxxxxx>
> [mailto:udig-dev-bounces@xxxxxxxxxxxxxxxx
<mailto:udig-dev-bounces@xxxxxxxxxxxxxxxx>]
Im Auftrag von Emily Gouge
> Gesendet: Freitag, 13.
November 2015 01:17
> An: udig
> Betreff: [udig-dev]
RendererCreatorImpl and
>
ConcurrentModificationException
>
> The following stack trace has
been reported to me recently as a
bug with our mapping application:
>
>
java.util.ConcurrentModificationException
> at
java.util.ArrayList.sort(ArrayList.java:1456)
> at
java.util.Collections.sort(Collections.java:175)
> at
>
org.locationtech.udig.project.internal.render.impl.RendererCreatorImpl
>
.createConfiguration(RendererCreatorImpl.java:225)
> at
>
org.locationtech.udig.project.internal.render.impl.RendererCreatorImpl
>
.getConfiguration(RendererCreatorImpl.java:609)
> at
>
org.locationtech.udig.project.internal.render.impl.RendererCreatorImpl
>
.reset(RendererCreatorImpl.java:640)
> at
>
org.locationtech.udig.project.ui.internal.RenderManagerDynamic.refresh
>
(RenderManagerDynamic.java:269)
>
>
> Hunting this down, I think it
has recently become an issue
because of some changes with the way
Java8 sorts lists. This post
describes the issue well:
>
http://onelineatatime.io/collections-sort-the-java8u20-modification/
>
> The code in the
RendererCreatorImpl the root of the
problem seems
to be these two lines of code:
>
List<InternalRenderMetrics>
layerfactories =
>
layerToMetricsFactoryMap.get(layer);
>
Collections.sort(layerfactories, new
RenderMetricsSorter(layers));
>
> In cases when two rendering
requests are made simultaneously it
is possible that the sort function
causes a concurrent modification
exception (even if the list doesn't
change).
>
> One simple way to resolve this
is to create a new array list to
sort one:
>
>
List<InternalRenderMetrics>
layerfactories = new
>
ArrayList<InternalRenderMetricsFactory.InternalRenderMetrics>(layerToM
> etricsFactoryMap.get(layer));
>
>
Collections.sort(layerfactories, new
RenderMetricsSorter(layers));
>
> Does anyone have any thoughts
on this? Perhaps there is a better
way to fix this issue?
>
> Thanks,
> Emily
>
>
_______________________________________________
> udig-dev mailing list
> udig-dev@xxxxxxxxxxxxxxxx
<mailto:udig-dev@xxxxxxxxxxxxxxxx>
> To change your delivery
options, retrieve your password, or
> unsubscribe from this list,
visit
>
https://locationtech.org/mailman/listinfo/udig-dev
>
>
________________________________
> IBYKUS AG für
Informationstechnologie, Erfurt / HRB
108616 - D-Jena /
> Vorstand: Helmut C. Henkel,
Dr. Lutz Richter Vorsitzender des
> Aufsichtsrates: Dr. Wolfgang
Habel
>
_______________________________________________
> udig-dev mailing list
> udig-dev@xxxxxxxxxxxxxxxx
<mailto:udig-dev@xxxxxxxxxxxxxxxx>
> To change your delivery
options, retrieve your password, or
> unsubscribe from this list,
visit
>
https://locationtech.org/mailman/listinfo/udig-dev
>
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
<mailto:udig-dev@xxxxxxxxxxxxxxxx>
To change your delivery options,
retrieve your password, or
unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/udig-dev
________________________________
IBYKUS AG für
Informationstechnologie, Erfurt / HRB
108616 - D-Jena
/ Vorstand: Helmut C. Henkel, Dr.
Lutz Richter
Vorsitzender des Aufsichtsrates: Dr.
Wolfgang Habel
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
<mailto:udig-dev@xxxxxxxxxxxxxxxx>
To change your delivery options,
retrieve your password, or
unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/udig-dev
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve
your password, or
unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/udig-dev
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit https://locationtech.org/mailman/listinfo/udig-dev
________________________________
IBYKUS AG für Informationstechnologie,
Erfurt / HRB 108616 - D-Jena / Vorstand:
Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr.
Wolfgang Habel
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://locationtech.org/mailman/listinfo/udig-dev
.
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://locationtech.org/mailman/listinfo/udig-dev
________________________________
IBYKUS AG für Informationstechnologie,
Erfurt / HRB 108616 - D-Jena / Vorstand:
Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr.
Wolfgang Habel
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://locationtech.org/mailman/listinfo/udig-dev
