Hi folks,
We have a few sizeable GeoServer catalogs… and a reload triggered via the REST API to /reload can take a few minutes. During this time GeoServer continues to listen on it’s port and queues requests up to process after the catalog is loaded, which isn’t ideal from a user-experience point of view.
Is there an extension hook to tie into around catalog (re)loading, which we could use to prevent traffic being routed to the Geoserver instance until it is all ready to go?
Thanks,
Rob 
On Tue, May 27, 2014 at 10:20 PM, Robert Coup
<robert.coup@anonymised.com>wrote:
Hi folks,
We have a few sizeable GeoServer catalogs... and a reload triggered via
the REST API to /reload can take a few minutes. During this time GeoServer
continues to listen on it's port and queues requests up to process after
the catalog is loaded, which isn't ideal from a user-experience point of
view.Is there an extension hook to tie into around catalog (re)loading, which
we could use to prevent traffic being routed to the Geoserver instance
until it is all ready to go?
Hmm... not quite, this is the closest thing I can think of, and it's wrong:
you'd need a couple of GeoServerLifecycleHandler implementations, oe at
very high ExtensionPriority, that listens to
onReset, and one at very low ExtesionPriorty, that listens to onReload,
that would mark the begin and end of a
reload cycle (reset is done first, then the reload is done, then the
handlers are notified that the reload happened).
And then have a DispatcherCallback using the above two informations to stop
all incoming requests threads
using some form of synchronization when we are between the two... however,
done this way, a simple reset
would just lock down everything, as the reload event would never come, and
besides, the logic would be
pretty much implementation dependent.
Nope, the GeoServerLifecycleHandler would have to be extended to offer also
a beforeReload callback,
and coded in such a way that the reload event gets fired even if the reload
fails catastrophically (that is,
in a final method) otherwise the server would remain locked down until
restart.
Regardless of the above... such system might interact pretty poorly with
the control-flow extension (which
would probably just decide to kill all requests because they have been
waiting for too long to be executed).
Cheers
Andrea
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Hi Andrea,
Sorry - I should have been a bit clearer. I can happily take the reloading GeoServer instance out of our load balancer if I can know when it needs to be out (via etcd). The load balancer will just stop passing on requests to that instance until it’s told otherwise. So I don’t need Geoserver to stop listening for requests.
On Wed, May 28, 2014 at 9:12 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
This sounds promising
Ideally, I guess (thinking through it a bit more)
geoserver startup (start) - notify to take instance out of rotation (not that it’s listening at this point) - ??
geoserver startup (complete) - notify to add instance into rotation - ??
geoserver reload (start) - notify to take instance out of rotation - GeoServerLifecycleHandler.onReset/High
geoserver reload (complete) - notify to add instance into rotation - GeoServerLifecycleHandler.onReload/Low
geoserver shutdown (start) - notify to take instance out of rotation - GeoServerLifecycleHandler.onDispose/High??
that should cover startups/shutdowns, as well as reloads
Hopefully avoiding messing with “listen on a port” will avoid this (complex) part?
Thanks,
Rob
On Tue, May 27, 2014 at 10:20 PM, Robert Coup <robert.coup@anonymised.com> wrote:
Is there an extension hook to tie into around catalog (re)loading, which we could use to prevent traffic being routed to the Geoserver instance until it is all ready to go?
Hmm… not quite, this is the closest thing I can think of, and it’s wrong:
you’d need a couple of GeoServerLifecycleHandler implementations, oe at very high ExtensionPriority, that listens to
onReset, and one at very low ExtesionPriorty, that listens to onReload, that would mark the begin and end of a
reload cycle (reset is done first, then the reload is done, then the handlers are notified that the reload happened).
And then have a DispatcherCallback using the above two informations to stop all incoming requests threads
using some form of synchronization when we are between the two… however, done this way, a simple reset
would just lock down everything, as the reload event would never come, and besides, the logic would be
pretty much implementation dependent.
Nope, the GeoServerLifecycleHandler would have to be extended to offer also a beforeReload callback,
and coded in such a way that the reload event gets fired even if the reload fails catastrophically (that is,
in a final method) otherwise the server would remain locked down until restart.
Regardless of the above… such system might interact pretty poorly with the control-flow extension (which
would probably just decide to kill all requests because they have been waiting for too long to be executed).
On Wed, May 28, 2014 at 1:58 AM, Robert Coup <robert.coup@anonymised.com>wrote:
And then have a DispatcherCallback using the above two informations to
stop all incoming requests threads
using some form of synchronization when we are between the two...
however, done this way, a simple reset
would just lock down everything, as the reload event would never come,
and besides, the logic would be
pretty much implementation dependent.Nope, the GeoServerLifecycleHandler would have to be extended to offer
also a beforeReload callback,
and coded in such a way that the reload event gets fired even if the
reload fails catastrophically (that is,
in a final method) otherwise the server would remain locked down until
restart.
Regardless of the above... such system might interact pretty poorly with
the control-flow extension (which
would probably just decide to kill all requests because they have been
waiting for too long to be executed).Hopefully avoiding messing with "listen on a port" will avoid this
(complex) part?
It will avoid some of it, but changes to the GeoServerLifecycleHandler
interface are unavoidable (we need
something marking the start of a reload)
This would be a breakage in a interface of a public extension point, which
means if someone does it, we might not be
able to backport it to the stable series.
Cheers
Andrea
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------