I was just thinking about how catalog objects tend to contain references to
other catalog objects (e.g., a layer contains a reference to a resource and one
or more styles and a resource contains a reference to a namespace and a store).
As long as the Hazelcast catalog events are able to properly propagate changes
to catalog objects across the cluster (since each node would have its own
instance of the object), then I do think that the Hazelcast cache may be
unnecessary.
I don't see why there would be any issues using jdbcconfig without a cluster.
Steve Ikeoka
________________________________
From: Niels Charlier <ni...@scitus.be>
Sent: Friday, July 6, 2018 7:21 AM
To: Ikeoka, Steve; Geoserver-devel
Subject: Re: [Geoserver-devel] hazelcast/jdbcconfig cache: why?
Hey Steve,
Thanks for your response.
Can you give an example of an issue with parent/child objects that could occur
in the catalog? I can't really think of any.
Changes to the catalog always apply to a single object, and avoiding references
to old versions of catalog objects is a general issue that is avoided by the
use of proxies.
Note also that this cache is only used by jdbcconfig. Jdbcconfig however can
also run without clustering, in which case it relies solely on the event system
to invalidate the cache when changes happen. So if that system doesn't work,
that wpould mean jdbcconfig can't work properly without hazelcast, which would
be an odd situation and is not really the case.
The use of these resources is all because of this cache, for which I really see
no purpose. A cache per node seems like the best idea.
Regards
Niels
On 05-07-18 21:53, Ikeoka, Steve wrote:
I agree with you that Hazelcast uses a lot of resources and can really slow
down getcapabilities requests but I don't have any more information about the
design of the Hazelcast clustering plugin and I don't have a cluster
environment to test with. If you've been able to thoroughly test the Hazelcast
clustering plugin without the Hazelcast cache then I would say it's okay to
remove it. One thing that you should test is that there are no issues with
parent/child objects when you are relying only on the catalog events to
distribute changes across the cluster. I think that that may have been part of
the reasoning for the cache serializing/deserializing the catalog data.
Steve Ikeoka
________________________________
From: Niels Charlier <ni...@scitus.be><mailto:ni...@scitus.be>
Sent: Thursday, July 5, 2018 5:16 AM
To:
geoserver-devel@lists.sourceforge.net<mailto:geoserver-devel@lists.sourceforge.net>
Cc: Ikeoka, Steve
Subject: Re: [Geoserver-devel] hazelcast/jdbcconfig cache: why?
Actually, @Steve Ikeoka has made changes to the hazelcast cache in recent times
(CC'ed).
I wonder if he has any experience/insight in this matter?
Regards
Niels
On 04-07-18 16:03, Niels Charlier wrote:
Hello Justin,
Thanks for your answer. I understand that the community status of the module
means that it can have some flaws. Not many have contributed to it in years
actually. I was just wondering about the intent of the original programmer,if
they still remember, so I am better equipped with knowledge to make
improvements.
Regards
Niels
On 04-07-18 15:16, Justin Deoliveira wrote:
I haven't committed to that module in many years so I am the wrong person to
ask. I would start by looking at someone who more recently has made changes to
it, someone from Boundless perhaps. I will say when I worked on it it was a
prototype, something that hadn't seen any use in production, so I am not
surprised if it has issues like this. Not an uncommon occurrence for community
modules I would say. Given no-one else has responded it seems safe for you to
make whatever changes to it you see fit.
On Wed, Jul 4, 2018 at 6:06 AM Andrea Aime
<andrea.a...@geo-solutions.it<mailto:andrea.a...@geo-solutions.it>> wrote:
On Wed, Jul 4, 2018 at 1:37 PM, Niels Charlier
<ni...@scitus.be<mailto:ni...@scitus.be>> wrote:
Nobody answers... does anyone know who developed this? Was it Justin?
I believe he was... see first commit in both these files:
https://github.com/geoserver/geoserver/commits/master/src/community/hz-cluster/src/main/java/org/geoserver/cluster/ClusterConfig.java<https://teamworksportal.gdit.com/geoserver/geoserver/commits/master/src/community/hz-cluster/src/main/java/org/geoserver/cluster/,DanaInfo=github.com,SSL+ClusterConfig.java>
https://github.com/geoserver/geoserver/commits/master/src/community/hz-cluster/pom.xml<https://teamworksportal.gdit.com/geoserver/geoserver/commits/master/src/community/hz-cluster/,DanaInfo=github.com,SSL+pom.xml>
Do we still have a maintainer for the hzcluster module?
No idea...
Regards
Andrea
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V<https://teamworksportal.gdit.com/,DanaInfo=goo.gl+it488V>
for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions
S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax:
+39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it<https://teamworksportal.gdit.com/,DanaInfo=www.geo-solutions.it+>
http://twitter.com/geosolutions_it<https://teamworksportal.gdit.com/,DanaInfo=twitter.com+geosolutions_it>
------------------------------------------------------- Con riferimento alla
normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento
generale sulla protezione dei dati "GDPR"), si precisa che ogni circostanza
inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è
un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo,
ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene
notizia. This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by European
Regulation 2016/679 "GDPR" - copying, dissemination or use of this e-mail or
the information herein by anyone other than the intended recipient is
prohibited. If you have received this email by mistake, please notify us
immediately by telephone or e-mail.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot<https://teamworksportal.gdit.com/,DanaInfo=sdm.link+slashdot>_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel<https://teamworksportal.gdit.com/lists/listinfo/,DanaInfo=lists.sourceforge.net,SSL+geoserver-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot<https://teamworksportal.gdit.com/,DanaInfo=sdm.link+slashdot>
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel<https://teamworksportal.gdit.com/lists/listinfo/,DanaInfo=lists.sourceforge.net,SSL+geoserver-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
