[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] uDig 1.1.1 Memory Leak
|
> It actually does not make sense to me that org.geotools.referencing.factory.DeferredAuthorityFactory.Disposer would be called during rendering ... so I am a bit confused by the source of this problem. In general the referencing code works in the background and provides definitions of coordinate reference systems as needed.
I maybe didn't explain myself properly. I raise this suspicion this way:
1) I've followed all the instructions in
http://udig.refractions.net/files/tutorials/SDKQuickstartStable.pdf
2) Tested using VisualVM and realised that by refreshing the map,
adding layers and removing layers after a while the memory would rise
irreversibly and so I analysed the heap dumps to find that it had lots
of DeferredAuthorityFactory.Disposer instances
3) Downloaded the Geotools 2.2.2 source since the 2.2.3 is no longer
available and linked to the net.refractions.udig.libs so I can debug
the code
4) Break point in the setTimeout method in
org.geotools.referencing.factory.DeferredAuthorityFactory
5) Debugged uDig and concluded that every refresh, pan, addyng layer,
remove layer does the following code:
In the class org.geotools.referencing.factory.DeferredAuthorityFactory:
public synchronized void setTimeout(final long delay) {
if (disposer != null) {
<-------------------------------- fails
disposer.cancel();
}
disposer = new Disposer();
TIMER.schedule(disposer, delay, delay);
<-------------------------------- source of the memory leak (delay =
30 min)
}
Thank you,
Pedro
On Wed, Jul 7, 2010 at 3:14 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
> It actually does not make sense to me that org.geotools.referencing.factory.DeferredAuthorityFactory.Disposer would be called during rendering ... so I am a bit confused by the source of this problem. In general the referencing code works in the background and provides definitions of coordinate reference systems as needed.
>
> On 07/07/2010, at 11:44 PM, Pedro Baia wrote:
>
>> On the start of my project I choose the latest stable version at the
>> time, uDig 1.1.1 and it's not possible to migrate to uDig 1.2 without
>> a big effort.
>
> Understood.
>
>> I couldn't find any issue related to this matter in the GeoTools
>> 2.2.x, GeoTools 2.3.x, or GeoTools 2.4.x. Does uDig 1.1.1 uses
>> GeoTools 2.2.3, I'm I right about this?
>
> I belive that is correct; I am a committer on the GeoTools project and I can make a new release of GeoTools if needed; it is just that
> 2.2.x is now at least five years old and I am not sure if it builds with a modern version of maven.
>
>> Is there a newer stable GeoTool release compatible with uDig 1.1.1?
>
> No.
>
>> Does that release solves this memory leak?
>
> I have not had a reported memory leak on uDig 1.2.x series which uses a newer version of GeoTools.
>
> Jody
>
>>
>>
>>
>> Thank you,
>>
>> Pedro
>>
>>
>>
>> On Wed, Jul 7, 2010 at 12:23 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
>>> Wow GeoTools 2.2.x is a long time ago; I think we can still build it. If you would like to submit a patch; you may be able to determine one by looking at GeoTools 2.3.x, 2.4.x and see when the issue was fixed.
>>>
>>> The GeoTools project is open to volunteers; and as a volunteer you can issue a older release of GeoTools - 2.2.4 in this case.
>>>
>>> Jody
>>>
>>>
>>> On 07/07/2010, at 8:55 PM, Pedro Baia wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm developing a software using uDig 1.1.1 that needs to create and
>>>> delete a large amount of layers. As I was testing the performance and
>>>> memory of my software I found that after a certain number of creating
>>>> and deleting actions it ran out of memory:
>>>>
>>>> java.lang.OutOfMemoryError: Java heap space
>>>>
>>>> I ran a test on uDig 1.1.1 adding and removing a shapefile with
>>>> approximately 58 MB and 4415 polygons (MultiPolygon) features and
>>>> found that it behaves in the same way.
>>>> Using the jVisualVM software provided by the jdk, and analyzing uDig
>>>> 1.1.1 heap dumps captured after some refresh, creating and deleting
>>>> actions, I found that a huge amount of memory was being used by lots
>>>> of instances of the class:
>>>>
>>>> org.geotools.referencing.factory.DeferredAuthorityFactory.Disposer
>>>>
>>>> Debugging with the GeoTools 2.2.3 source I found that the method
>>>> setTimeout((final long delay)) of this class is being called every
>>>> time the program renders or filter is applied to a layer.
>>>>
>>>> I consider this a memory leak and my question is what can I do to
>>>> prevent going out of memory.
>>>>
>>>>
>>>>
>>>> Thank you,
>>>>
>>>> Pedro
>>>> _______________________________________________
>>>> User-friendly Desktop Internet GIS (uDig)
>>>> http://udig.refractions.net
>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>>> _______________________________________________
>>> User-friendly Desktop Internet GIS (uDig)
>>> http://udig.refractions.net
>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
