The scenario you're talking about (PostgreSQL layers + base ecw
image layer) is very usual with Kosmo Desktop and we haven't found
issues about memory exhausting while panning before: we have systems
that are using 500 Gb image directories as base image layer plus
10.000.000+ feature PostgreSQL layers and it doesn't have that
Could you give me some more info about your current scenario in
order to give you some hints?
- Kosmo Desktop version: 2.0, 2.0 rc1 or 2.0.1?
- PostgreSQL layers:
+ Number of features
+ Geometry types
+ Number of layers
- Base image layer
+ Is it an unique file or a mosaic of them?
- Are there more layers loaded (shapefiles, CAD files, etc.) apart
The memory recovery button is just inherited from the base JUMP, but
it shouldn't be necessary to use it at all: when Java VM hits the
maximum available memory it should make automatically the same call
to the garbage collector as the button does.
Tip: in your Kosmo.bat/Kosmo.sh launcher, you can set up more memory
for your Kosmo Desktop installation in order to increase performance
if you have enough memory in your system.
start.\jre\bin\javaw -Djava.library.path="..\dlls" -cp
Change -Xmx800M to -Xmx1024M or -Xmx1200M to see if the application
El 23/05/2012 9:46, Fernando Perfumo escribió:
I'm using Kosmo desktop 2.0 and PostgreSQL.
The base image is a .ecw file of about 500 MB.
I noticed that panning the map exhaust the system memory, and I
need to free
it frecuently by hand.
Does somebody know the reason to keep the memory recovery an user
Wouldn't be better freeing the user of this task?
I use Kosmo for a traffic ligths control gis, and found it a very
application, despite java gas-like behaviour.
One reason can be that the ECW-binaries are reserving some memory when user is panning around. That is for making it faster to revisit the same area again. That memory is freed after 10 (or perhaps 20) minutes, I do not remember exactly right now. You can test it by panning around wildly and then by doing nothing and following the memory usage.
All softwares using ecw dll files behave in a similar way (OpenJUMP, gvSIG, even ER Viewer) at least with ECW JPEG SDK version 3.x.
Windows system manager reports in this case that memory is reserver by Java but actually it is reserved outside Java by the ecw binaries. If this is what happens to you is is usually not dangerous and there is nothing you can do. One thing may help still: do not keep very many ECW files open at the same time.