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