Folks,
a I have a long-time wish of making GeoServer truly scalable; to this end a persistence mechanism other than XML files is clearly needed, hence I started looking into dbconfig.... and I've got a couple questions, could someone confirm/deny the following ?
1) The cache (EHCache) is not distributed, hence it could be used only when there is exactly one instance of GeoServer connected to the configuration database (alternatively, a configuration reload command can be broadcast to all GeoServer instances at every configuration change).
2) Security is not persisted to database, hence it has to be updated instance by instance.
Thanks in advance,
Luca Morandini
http://www.lucamorandini.it
Hi Luca,
Hi Luca,
Unfortunately dbconfig is sort of out in no mans land… and potentially going to be dropped in favour of a different non hibernate based solution. See recent proposals from Gabriel.
Although if a developer were interested in maintaining the module it could be brought back to life. That said some comments inline.
On Thu, Feb 23, 2012 at 9:48 AM, Luca Morandini <lmorandini@anonymised.com> wrote:
Folks,
a I have a long-time wish of making GeoServer truly scalable; to this end a
persistence mechanism other than XML files is clearly needed, hence I started
looking into dbconfig… and I’ve got a couple questions, could someone
confirm/deny the following ?
- The cache (EHCache) is not distributed, hence it could be used only when there
is exactly one instance of GeoServer connected to the configuration database
(alternatively, a configuration reload command can be broadcast to all GeoServer
instances at every configuration change).
Correct, although i guess it could be possible to configure a distributed cache… never done this myself with hibernate.
- Security is not persisted to database, hence it has to be updated instance by
instance.
Correct. There are actually a few things that are not, security being one of them. Style files and SLD’s being another.
Thanks in advance,
Luca Morandini
http://www.lucamorandini.it
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On 02/23/2012 06:46 PM, Justin Deoliveira wrote:
Unfortunately dbconfig is sort of out in no mans land... and potentially going to
be dropped in favour of a different non hibernate based solution. See
recent proposals from Gabriel.
I think I've missed it: do you mind pointing it out ?
Although if a developer were interested in maintaining the module it could be
brought back to life.
Ahem, actually I was toying with an alternative idea... something simpler, something more scalable (just mumblings at the moment).
Thanks for your prompt reply,
Luca Morandini
http://www.lucamorandini.it
On Thu, Feb 23, 2012 at 11:29 AM, Luca Morandini <lmorandini@anonymised.com> wrote:
On 02/23/2012 06:46 PM, Justin Deoliveira wrote:
Unfortunately dbconfig is sort of out in no mans land… and potentially going to
be dropped in favour of a different non hibernate based solution. See
recent proposals from Gabriel.
I think I’ve missed it: do you mind pointing it out ?
Gabriel sent out a detailed email a while back but i can’t seem to find it anywhere. Anyways, basically the idea is to use a key value store for catalog / configuration, and he has been experimenting mostly with berkely db but i think he has implementations on top of a relational database.
You can find the code in his github repo:
https://github.com/groldan/geoserver/tree/scalability
And the pending proposals in support of the work:
http://geoserver.org/display/GEOS/GSIP+69±+Catalog+scalability+enhancements
http://geoserver.org/display/GEOS/GSIP+70±+Reduce+CatalogFacade+API
Although if a developer were interested in maintaining the module it could be
brought back to life.
Ahem, actually I was toying with an alternative idea… something simpler,
something more scalable (just mumblings at the moment).
Thanks for your prompt reply,
Luca Morandini
http://www.lucamorandini.it
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On 02/23/2012 12:46 PM, Justin Deoliveira wrote:
Unfortunately dbconfig is sort of out in no mans land... and potentially
going to be dropped in favour of a different non hibernate based
solution.
As was pointed out to me recently on the list, "scalability" is often required to handle families of time-related layers, which can (should) be placed into a single layer with a time parameter.
Not every layer type supports the parameter yet, but ImageMosaic does, I believe PostGIS does, and it wasn't too difficult to implement on my own custom layer type.
Luca, I'd suggest looking into this as a possibility; it worked like a charm for me.
hth
On 03/05/2012 02:23 PM, John Armstrong wrote:
On 02/23/2012 12:46 PM, Justin Deoliveira wrote:
Unfortunately dbconfig is sort of out in no mans land... and potentially
going to be dropped in favour of a different non hibernate based
solution.
As was pointed out to me recently on the list, "scalability" is often
required to handle families of time-related layers, which can (should)
be placed into a single layer with a time parameter.
Well, I was thinking of scalability more in terms of availability (like the clustering of GeoServer instances) than in terms of number of layers; and this issue could be well handled by using a catalog based on a key-value database like BerkeleyDB (which is precisely what Gabriel is doing, albeit at a slow pace).
Regards,
Luca Morandini
http://www.lucamorandini.it