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 <[email protected]> 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
