Thanks Neils, that approach matches my idea - I had in mind placing a
listener on each style directory - and had hoped that we had relatively few
other folders to track. I particular I was designing for a clustered
environment and had hoped cluster workload could be sharded a bit by
workspace (so each node may only end up actively watching a couple style
directories...)
I thought I had a single listener list and path matching to handle event
notification. The add/remove listener methods on a single resource were an
illusion (as resource if often a flyweight object).
public void addListener(ResourceListener listener) {
FileSystemResourceStore.this.addListener( file, path, listener
);
}
Which called through to:
public synchronized void addListener(File file, String path,
ResourceListener listener) {
if( watcher == null ){
watcher = new FileSystemWatcher();
}
watcher.addListener( file, path, listener );
}
>From my perspective listeners methods are available on individual
resources, but I expect the resources to be fly weights and not be
responsible for that state themselves.
I cannot really see the difference between this and how the other
clustering solutions get away with just registering a catalog listener?
I double checked and was a bit disappointed not to find anything more then
a catalog listener in the clustering solutions - but I guess it makes
sense. Can I turn this question around? Is there any advantage to having a
single "cluster event dispatch" that could be used by JDBCConfig,
JDBCResourceStore and the clustered WPS implementation?
--
Jody Garnett
On 21 December 2015 at 02:38, Niels Charlier <ni...@scitus.be> wrote:
> 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> 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
