Alright. What the clustering modules do is simply registering itself as
a CatalogListener and then dispatch events to other geoserver instances.
This is a fine strategy for the catalog, I don't see any reason to
change it.
The problem is that with resources, listeners are always placed on a
particular resource. I guess there is one way to do it using a similar
strategy which I hadn't thought of before (and, admittedly, a fourth
option to the list I previously claimed was exhaustive) and that to let
the hazelcast module register as a listener to the Root resource (which
should receive a notification for every change), rather than
implementing a ResourceNotificationDispatcher. However, that would be
first of all a much uglier, more round-about and more bug-prone way of
doing things than what I did. Furthermore, what I did places code that
is likely reusable by other implementations of stores/clusters in a
shared space.
Regards
Niels
On 19-12-15 01:03, Jody Garnett wrote:
Comments inline on event distribution ... and then we should be good
to go. If it helps I think we can seperate event notification
(generating events/listening for events) from event distribution (in a
cluster, recorded in an audit log).
On 18 December 2015 at 07:04, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
no problem: because this isn't being enforced. The ResourceStore
already provides the API needed for adding handlers to resources
and this remains unaltered, the programmer who uses Resources need
not worry about the existence of the ResourceWatcher as they never
need to use it. Alternative implementations of ResourceStore may
choose to use it, which would be recommended if they wish to
support clustering, but that is all.
So the missing bit for me is the hazelcast and jms plugins - they both
implement an interface for event distribution. I expected
JDBCResoruceStore work to integrate smoothly with that ... but had not
looked into the details.
Two questions:
- If you are really focused on event dispatch can we rename
the interface to match?
Sure, ResourceNotificationDispatcher then.
Thanks that helps keep my head from exploding.
- Should we have an event dispatch mechanism that works in a
similar fashion for catalog and resource change events?
Bit confused, resource change events is what we are talking about.
Catalog: good point. I don't know if there is a mechanism in place
for distributing these in a clustered environment, but if not we
do need such a mechanism. It is possible this can be solved with a
different mechanism.
There is a mechanism, and two implementations. I would like to combine
forces rather than duplicate.
Implementations:
-
https://github.com/geoserver/geoserver/tree/master/src/community/hz-cluster
-
https://github.com/geoserver/geoserver/tree/master/src/community/jms-cluster
Can you take a moment to look at those and tell me what you think?
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
