Yes, ecw code seems to access the files directly through the native code and
new images are created for the view requested. I found this interesting bit
though
http://iws.erdas.com/forum/memory-leak.aspx
jukka could you try to fill your memory up a bit and wait for say 30 minutes
and see if the memory reduces if nothing is requested?
The explicit file closing with true for cache cleanup on layer removal is
something i think about putting in, though i am still not sure where to hook in.
..ede
On 29.09.2011 18:54, Stefan Steiniger wrote:
> this answer probably doesn't help as i do not know the gvSIG code,
> and is more of a note:
>
> I think for mrsid code created images in a temporary sub folder of oj.
> Processing in sextante also writes rasters to a folder. For intermediate
> results these are deleted (if the code is written), but final processing
> results are stored in windows temp (and the user needs to clean them
> up). Though... ECW may work completely differently
>
> On 29/09/2011 7:24 AM, edgar.sol...@web.de wrote:
>> i can reproduce this, actually the memory is not even freed when the layer
>> is removed from the task.
>>
>> removing layers seems to work like this
>>
>> - RemoveLayerPlugin execute
>> - fill layer with empty feature collection
>> - remove layer from layermanagement
>>
>> problem is: there is no active cleanup, the best i found was a finalize()
>> method in the ecw java binding code
>>
>> src-ecw/com/ermapper/ecw/JNCSFile.java
>> protected void finalize()
>> throws Throwable
>> {
>> if(bIsOpen)
>> ECWClose(true);
>> super.finalize();
>> }
>>
>> but it seems like oj never reaches there, or better i set a debug point
>> there but gc'ing does not reach it.
>>
>> any ideas, anyone?
>>
>>
>> ede
>>
>> PS: i fetched the jecw java/native sources from gvsig, so we are gpl
>> compliant by having it available at least in our svn
>>
>>
>> On 28.09.2011 16:18, Jukka Rahkonen wrote:
>>> Hi,
>>>
>>> There is one 12000x12000 JPEG2000 image for you at
>> SNIP
>>> It is lossless and therefore still 181 MB in size. Open it with OJ, zoom
>>> and pan wildly around and you will see how java.exe will take more and
>>> more memory.
>>>
>>> -Jukka-
>>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
