Hi,
today I'm looking at the bits of code that do force the resource
pool and catalog reload.
What I would like to add is a call to ImageGraphicFactory.reset()
to clean up the SLD external symbolizers cache.
I can just add it, but it's starting to look a little messy,
the code to reload the resource pool is already called in three
places and the one to reload the catalog in two (Status page,
Catalog reload restlet).
Is it time to centralize this business into two methods, which
might be:
resetCaches() (resets the resource pool, image cache, maybe
something else tomorrow)
reloadConfiguration() (does the above and reloads the catalog)
The GeoServer interface seems like a decent place to do that,
as we have already a dispose() method and the two above seem to
do a similar business, but I may be wrong.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
org.geoserver.config.GeoServer seems like a perfect match to me API wise, then implementation can release stuff from wherever its necessary.
2c.-
Gabriel
On 5/14/10 10:45 AM, Andrea Aime wrote:
Hi,
today I'm looking at the bits of code that do force the resource
pool and catalog reload.
What I would like to add is a call to ImageGraphicFactory.reset()
to clean up the SLD external symbolizers cache.
I can just add it, but it's starting to look a little messy,
the code to reload the resource pool is already called in three
places and the one to reload the catalog in two (Status page,
Catalog reload restlet).
Is it time to centralize this business into two methods, which
might be:
resetCaches() (resets the resource pool, image cache, maybe
something else tomorrow)
reloadConfiguration() (does the above and reloads the catalog)
The GeoServer interface seems like a decent place to do that,
as we have already a dispose() method and the two above seem to
do a similar business, but I may be wrong.
Opinions?
Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Well the problem with loading the interface up with implementation specific stuff is that it is harder to implement. The folks trying to implement the Catalog interface for hibernate ran into this issue and the result was a lot of duplicated code. That said I think at some point we need to break out a GeoServerDAO interface like we plan to do for Catalog.
Sorry, I digress. I think the GeoServer interface makes sense. Can we make the method names a bit less implementation specific:
reset()
reload()
With dispose() they form a nice concise trifecta
2c.
-Justin
On 10-05-14 8:06 AM, Gabriel Roldan wrote:
org.geoserver.config.GeoServer seems like a perfect match to me API
wise, then implementation can release stuff from wherever its necessary.
2c.-
Gabriel
On 5/14/10 10:45 AM, Andrea Aime wrote:
Hi,
today I'm looking at the bits of code that do force the resource
pool and catalog reload.
What I would like to add is a call to ImageGraphicFactory.reset()
to clean up the SLD external symbolizers cache.
I can just add it, but it's starting to look a little messy,
the code to reload the resource pool is already called in three
places and the one to reload the catalog in two (Status page,
Catalog reload restlet).
Is it time to centralize this business into two methods, which
might be:
resetCaches() (resets the resource pool, image cache, maybe
something else tomorrow)
reloadConfiguration() (does the above and reloads the catalog)
The GeoServer interface seems like a decent place to do that,
as we have already a dispose() method and the two above seem to
do a similar business, but I may be wrong.
Opinions?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Well the problem with loading the interface up with implementation specific stuff is that it is harder to implement. The folks trying to implement the Catalog interface for hibernate ran into this issue and the result was a lot of duplicated code. That said I think at some point we need to break out a GeoServerDAO interface like we plan to do for Catalog.
Sorry, I digress. I think the GeoServer interface makes sense. Can we make the method names a bit less implementation specific:
reset()
reload()
With dispose() they form a nice concise trifecta
Cool. Yeah, I think those methods could be useful for a hibernate based
catalog as well, thinking second level cache here.
However to hook that up we'd need to call some cleanup method at
the catalog level....
Oh well, centralize first, we can refactor the implementation later
(and do so in a single place instead of 2-3)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Well the problem with loading the interface up with implementation specific stuff is that it is harder to implement. The folks trying to implement the Catalog interface for hibernate ran into this issue and the result was a lot of duplicated code. That said I think at some point we need to break out a GeoServerDAO interface like we plan to do for Catalog.
Sorry, I digress. I think the GeoServer interface makes sense. Can we make the method names a bit less implementation specific:
reset()
reload()
With dispose() they form a nice concise trifecta
Cool. Yeah, I think those methods could be useful for a hibernate based
catalog as well, thinking second level cache here.
However to hook that up we'd need to call some cleanup method at
the catalog level....
Oh well, centralize first, we can refactor the implementation later
(and do so in a single place instead of 2-3)
Ah, one important bit. GeoServer cannot should not/can not know about
all the caches that are around. In particular dropping the rendering
ones is the WMS service business, not the core GeoServer one.
So I guess we need to roll out a cache clearing extension point.
Something like:
GeoServerResetHandler {
public void reset();
}
Maybe with a nicer name?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Well the problem with loading the interface up with implementation
specific stuff is that it is harder to implement. The folks trying to
implement the Catalog interface for hibernate ran into this issue and
the result was a lot of duplicated code. That said I think at some
point we need to break out a GeoServerDAO interface like we plan to
do for Catalog.
Sorry, I digress. I think the GeoServer interface makes sense. Can we
make the method names a bit less implementation specific:
reset()
reload()
With dispose() they form a nice concise trifecta
Cool. Yeah, I think those methods could be useful for a hibernate based
catalog as well, thinking second level cache here.
However to hook that up we'd need to call some cleanup method at
the catalog level....
Oh well, centralize first, we can refactor the implementation later
(and do so in a single place instead of 2-3)
Ah, one important bit. GeoServer cannot should not/can not know about
all the caches that are around. In particular dropping the rendering
ones is the WMS service business, not the core GeoServer one.
So I guess we need to roll out a cache clearing extension point.
Something like:
GeoServerResetHandler {
public void reset();
}
Maybe with a nicer name?
Good idea. Maybe we just have one interface for all events. Something like:
GeoServerLifeCycleHandler {
void onDispose();
void onReset();
void onReload();
}
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Not sure; there are so many magic maps keeping things unique that I would personally hunt down each one, check the geneva conventions for inter generation memory crimes and systematic violation of garbage collection and ...
Jody
On 17/05/2010, at 1:36 AM, Andrea Aime wrote:
Jody Garnett ha scritto:
Did you already clear out the referencing caches and connections?
As a matter of fact, nope, I did not, nice catch.
Would calling
CRS.reset("all")
be enough. Can you think of a better way?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
