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
<[email protected]>wrote:
> On Tue, May 27, 2014 at 10:20 PM, Robert Coup <[email protected]
> > 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).
>
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
> 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?
Thanks,
Rob :)
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
