Re: [udig-devel] Memory usage best practices, and old postgis layer leak?

[Mark Leslie]

Jody's brought this to my attention so I'll have a look at it later this 
evening.  I agree that there shouldn't be any leaks, and it's concerning 
that you may have found one.  PostGIS support should be one of our more 
stable datastores.
We'll let you know what we find.
--
Mark

Jody Garnett wrote:
A couple quick answers...

There really should not be a memory leak :-) Have you tested with a
profiler to see what is holding onto the memory? I know we can control
how many rows the jdbc driver gulps down at a time (default is 200 or
something). Is it a constant memory leak - or does it get worse over
time ... each pan or zoom etc should issue a new request; so the
metric of 6 megs per layer does not make much sense to me right now.

Upgrading to 1.2 should not help or hinder this issue; but until we
find the cause I cannot tell for sure.

The best way to plan for a stable 1.2 release is to help out in the
code sprint Jesse is planning. This will both give you a feel for
where the code base is at; and give you a first hand impression of
where we are at. I am doing a tutorial around uDig 1.2 at FOSS4G this
year; and I have a set feature list in mind - however I am willing to
cut scope to get a release out so your volunteer efforts would be
helpful :-)

Jody




On Wed, Jun 3, 2009 at 5:57 AM, David Middlecamp
<dmiddlec...@avencia.com> wrote:
Hi Everybody,

 Having done some research, it seemed like the time to ask the
experts...  (it's a development question, really)

I'm currently developing a application based on the uDig 1.1.1 sdk, and
I think I've spotted a memory leak during some recent performance testing.
The strange part is that it's such a typical use case that I'm
sure someone must have spotted it ages ago.  I tried to find references
to it across the archives (the last 6 months), the bug tracking for
Geotools, and the bug tracking for uDig over the last five years, and I
think I've found a few candidates (about 10 known issues), but I'm not
sure if they apply.

Here's our test scenario:
I tested this across uDig 1.1.1, and uDig 1.2-M4, and our application
based on 1.1.1
Our test map had 2 shapefile layers (small shapefiles, unprojected)
And 2 postgis layers, a basic table, no filters, etc.

only step:  Cause the map to redraw (and, in theory, query the
datastore)...  (panning, zooming, hitting refresh, etc)  (this can't
be right, right?)

I rigged up our application to output actual used heap space, but for
uDig 1.1.1, and 1.2-M4 I used the Task Manager...

 During my tests, doing the same number of refreshes, etc, both uDig
1.1.1, and my application (no surprise), leaked about 6 megs per postgis
layer in the span of a few minutes.  I know the vm heap size in the
task manager doesn't reflect the actual memory used, so it's not
helpful when trying to diagnose a leak like this.
I would really like to upgrade to 1.2, but without actually heavily
modifying my application to work with 1.2, I can't tell if this
particular issue was fixed or not.

 We're really excited here to use the fixes and new features in the 1.2
release, but is it too soon to merge 1.2-M4 into our production code?
(Is there a date in mind for a 1.2 stable release?)  Also what uDig
best practices have people used to minimize their footprint,
and increase stability over long running times?

Thanks,
David


_______________________________________________
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