<div dir="ltr"><div>Hi<br><br>Georgi is leading into the
correct direction, but he is missing the Core Cache and some other
caches (e.g. image cache) that spread across OpenCms, as well as
OpenCms' event system.<br>
<br>But the main problem in using a distributed cache like Ehcache
ist that cached objects have to be serializable. Otherwise they cannot
be transferred from one JVM to another. Most Objects that are cached in
the core cache are serializable, but the Flex Cache entries aren't.<br>
Another problem is with singleton objects. While in a single JVM
application it is legal to compare singleton objects (or better
references to singleton objects) with == and != (but you still
shouldn't), it brings up problems in distributed applications where each
instance has its own JVM and thus their own "singleton" objects. When
those objects are serialized on one VM and deserialized on another, they
are different from their counterparts on that VM. Instead you have to
use equals() or if they box primitives compare those primitive values
instead.<br>
<div>Sadly some core cache objects in OpenCms are singletons and
in some places equality and inequality of references to those objects
are checked with == and !=.<br></div><div><br></div>The other way to
cluster OpenCms is to let all instances keep their own caches and send
flush notifications on publish events to all the other nodes, if one
instance manipulates the underlying database entries of cached objects. I
guess this mainly is what other solutions do - and Achim on request by
hand ;).<br>
<div>One drawback of this approach is, that you can access the
workplace and offline project only through one node that is the master
and propagates his publish events to the slaves.<br></div><div>If the master goes down, you are not able to edit your website. <br>
</div><div><br></div>Together with Arash Kaffamanesh from Clouds Sky I
am currently working on a cloud-ready and thus distributable and
cluster-ready version of OpenCms (based on 8.5.0) that follows the first
approach with a distributed cache where possible.<br>
<br><div>Our goals are:<br></div><div>- unlimited number of cluster nodes<br>- auto-discovery</div><div>- autoscaling (up and down)<br></div><div>- auto-recognition of new nodes<br></div><div>-
zero configuration (or at least identical configuration): all instances
have the same configuration, that's true also for OpenCms configuration
<br>
</div><div>- no master/slave design - all nodes are equal<br></div><div>-
fault tolerance - removing one node won't hurt others. this implies
that every node can serve the workplace at ANY time with sticky sessions<br>
<br></div><div>So far we have a distributable core cache and propagation of OpenCms events to all active cluster nodes.<br>Thus,
the core cache won't have to be flushed on publish events and the Flex
cache will flush online on all nodes on publish events just as usual.
Even static export on demand is working.<br>
</div><div>We have haproxy in front with sticky sessions, and we are
able to access the workplace just through it - no matter to which node
haproxy is directing on session creation. In the broadcast admin tool,
we see all user sessions and can send messages to all users.<br>
</div><div><br></div><div>All instances can startup the same from image image, i.e. a webapp that is copied from a template, or a complete vm image.<br><br></div><div>We
also wanted to be able to perform module updates much faster and more
reliable than it is possible with OpenCms' admin interface.<br>
</div><div>Therefor we are developing a driver that reads modules (at
least our own) and their contents directly from the real file system.
Now when we have an update we just have to deploy it to our template
folder, update the nodes with rsync, git or whatever and restart tomcat /
reload the webapp. If you do this one after another there won't be a
downtime at all - only your workplace users will lose their session.<br>
</div><div>No periods of unavailability of your website during module updates anymore!<br></div><div>As
a side effect, we could also reduce our development time for our own
modules as well! No more time wasting module uploads, rfs/vfs
synchronization or coding JSPs in the browser ;)<br>
<br></div>As Clouds Sky is a silver sponsor of OpenCms days 2013,
we are planning to do a presentation there and hopefully get everything
ready until then to show how OpenCms can autoscale on Amazon EC2 or
Eucalyptus.<br><br><br></div><div>Best regards,<br>Stephan<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/31 Georgi Naplatanov <span dir="ltr"><<a href="mailto:gosho@oles.biz" target="_blank">gosho@oles.biz</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I think that running OpenCms in a cluster won't be a problem if:<br>
<br>
- you use 1 db server or all db servers use synchronous replication<br>
- some parts of application folder are shared between all OpenCms instances (Samba or NFS), like /export/ folder<br>
- network enabled FlexCache cache implementation, like Ehcache.<br>
<br>
As Achim mentioned in this list, OCEE module is not expensive (at least for western Europe standard), so you may decide to do something else.<br>
<br>
Best regards<span class="HOEnZb"><font color="#888888"><br>
Georgi</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 07/30/2013 06:13 PM, jmcl wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would like to use OpenCMS in cluster.<br>
All I need to do is use it in a scenario where *no* content is served from<br>
the export folder. All content is served directly from the OpenCMS web app<br>
and is, if necessary, cached on a external cache engine like Varnish.<br>
I understand that having two OpenCMS nodes may cause problems when it comes<br>
to *adding* or *changing* content (at least I think there can be problems).<br>
Now, as for *serving* content would this be a problem???? I don't seen what<br>
problems can arise from having two OpenCMSes running at the same time, as<br>
web apps that they are, and externally balanced.<br>
Any comments on this, that don't directly involve the OCEE module, are<br>
welcome.<br>
Regards.<br>
<br>
J.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://opencms.996256.n3.nabble.com/OpenCMS-8-5-2-in-Cluster-tp23501.html" target="_blank">http://opencms.996256.n3.<u></u>nabble.com/OpenCMS-8-5-2-in-<u></u>Cluster-tp23501.html</a><br>
Sent from the OpenCMS mailing list archive at Nabble.com.<br>
______________________________<u></u>_________________<br>
This mail is sent to you from the opencms-dev mailing list<br>
To change your list options, or to unsubscribe from the list, please visit<br>
<a href="http://lists.opencms.org/cgi-bin/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/cgi-<u></u>bin/mailman/listinfo/opencms-<u></u>dev</a><br>
<br>
<br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
This mail is sent to you from the opencms-dev mailing list<br>
To change your list options, or to unsubscribe from the list, please visit<br>
<a href="http://lists.opencms.org/cgi-bin/mailman/listinfo/opencms-dev" target="_blank">http://lists.opencms.org/cgi-<u></u>bin/mailman/listinfo/opencms-<u></u>dev</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>