RE: Jahia Clustering - JMS

At 15:52 02/05/2005, you wrote:
>So on top of which platform are you currently runnning Jahia?
>
>As Jahia is distributed and tested by default with Tomcat, it is easier to 
>find Jahia support in this context.  All the documentation of
>Jahia is made with assumption that we have Tomcat. So we currently use Tomcat.

I am sure that JBoss is offering commercial support for Tomcat and JMS ;-)
But, even if most of the docs and tests are conducted against Tomcat 
(because it is difficult to ask to the community to test each of their 
changes against a dozen of "compliant" J2EE application server!), some of 
our customers are running Jahia on BEA or IBM (at least for the CMS layer. 
For the portal layer, yes, you will need 5to wait for the JSR168 support).

>If you run Jahia on top of Tomcat, why would you prefer a commercial JMS 
>server but are using an open source servlet container?
>
>If we wish to put a solution with fully redundant cluster, we found very 
>little Open support product that can offer ”Clustering” solution with 
>commercial support.  I will check the last link that you sent to me to 
>found new one.  For the moment, I find much more robust products like IBM 
>MQSeries than OpenJMS.  Well on, this has a price, I know.

Mmmh! The JMS layer is only used in Jahia in order to synchronize caches 
among the various nodes of the cluster. It is far less strategic than the 
application server. If for example one Jahia server is down and you restart 
it, all its caches will be initially empty. So all the connections will go 
back to the database (or will be bit by bit completed by the other nodes). 
So this synchronisation layer is only heavily required if you have two 
authoring servers. If you JMS server fails, then an author on server A may 
update some content which will not be available on server B (if and only if 
it was previously cached on server B). So this is the main risk for Jahia. 
But depending of the load balanced architecture you want to put in place I 
am not sure that the JMS server will be the bottleneck or the key asset to 
cover. In this sense the servlet container is far more strategic.

>And you also have commercial companies supporting open source (JMS) 
>implementations (e.g. Jboss)?
>
>We do not draw aside the possibility of using Open Source, but we must 
>precisely be able to have commercial support.

As said I am sure that JBoss Inc offers both support on Tomcat and JMS.

>Else we may switch to JGroups in the near future for performance reasons 
>(at the place of JMS)
>
>This point is very important for everyone, is this possible to elaborate a 
>little more on the Jahia orientations (in which version of Jahia and when) 
>for the clustering solution?
>
>Now, here my questions:
>
>In a context that we wish to put a robust infrastructure, I don’t 
>understand why we chose to first go with a JMS Server and now for the 
>future with JGroups? If we simply put robustness to our Database server 
>(Database server in cluster), we can easily choose to put the Jahia cache 
>in a table?  Why, this strategy was not retained?

I am not the expert on this area, but if I remember correctly JMS 
communicate on a one-to-one basis with each node in the cluster when 
JGroups directly broadcasts all changes to all the nodes.

Then regarding caches, they are absolutely necessary in an architecture 
such as Jahia with a low-level granularity (permissions, versions, locks, 
etc on each object of content) for obvious performance reasons. Each access 
to the database is very costly. So the goal is to avoid as much as possible 
any DB access. Of course one option would be to store in the DB the caches 
hashtables, but here also I am not sure we will then gain as much 
performance as we want. Some operations requires a lot of caches flushes. 
In memory this is easy and fast. In a database this will results in a lot 
more of selects and deletes operations... Why then MySQL integrated 
natively a cache proxy 
(http://dev.mysql.com/doc/mysql/en/query-cache.html)? And I can guarantee 
to you that turning on such a cache will result in a severe performance 
boost ;-) and this is critical to serve web pages (users are used to have 
their pages served in some milliseconds and Jahia may requires hundreds 
(even thousanded in edit mode) of SQL queries in order to display a page. 
Imagine the DB load with dozens of simultaneous hits!) .

Then coming to the direct future for the load balancing "module"(= for 
Jahia 4.5), we are currently working on several points:
- Jahia back-end object caches: convert them to use Hibernate 
(http://www.opensymphony.com/oscache/) + OSCache 
(http://www.opensymphony.com/oscache/). Ideally the cache implementation 
should be "vendor neutral" in order to support for example commercial 
implementation such as Tangosol (http://www.tangosol.com/).
- Jahia front-end HTML caches: Support for the JSR128 standard 
(http://jcp.org/en/jsr/detail?id=128) + implementation of an ESI compliant 
server (http://www.esi.org/). Here again the underlying cache system will 
certainly be by default OSCache even if this is not finally decided yet. 
This will then allow you to easily install several front-end cache server 
to reduce the load on the core Jahia servers. This will also allow us to 
manage HTML fragments at the container level and not only on a per page 
level. Currently flush operations are too "massive" in Jahia as we often 
need to flush a lot of pages just for a typo modification on a container.
- Cache pre-loading and serialization on disk: Current 32 bits JVM are 
limited to 1.5 GB of RAM. This creates a real issue for us as Jahia is 
quite memory consuming (especially if you have a lot of pages as the HTML 
cache needs to store one copy of the page per language, mode and user. Of 
course you can limit the size of the HTML cache (highly suggested to avoid 
some out-of-memory error if you have a lot of pages) but this is not really 
performing then). So the idea is to extend the memory caches to disk. This 
is a bit slower than memory but faster than going to the DB. The other 
advantage is that, at reboot, we may be able to directly reload the entire 
caches from disk.
- Load-balancing: We will try to remove the sticky session limit we 
currently have. Then the load could be better split among the nodes in the 
cluster. The second point, already mentionned, is the move to JGroups. Both 
of these points are subject to the time we have for Jahia 4.5 and may be 
delayed until Jahia 5.0.

Finally if we can convert all our caches (front-end and back-end) to rely 
only on OSCache, you will then be able to choose if you want to use JMS or 
JGroups (cf: http://www.opensymphony.com/oscache/wiki/Clustering.html).

I think that's all for the moment ;-)

Cheers,
Stéphane


>
>Thanks for your recommandation.
>
>
>
>----------
>De : Stéphane Croisier [mailto:[email protected]]
>Envoyé : 2 mai 2005 08:48
>À : [email protected]
>Objet : RE: Jahia Clustering - JMS
>
>Hi,
>
>All the certified J2EE application servers provided by the usual 
>commercial vendors (IBM; BEA; SUN;...) supports JMS as this is part of the 
>J2EE standard. So on top of which platform are you currently runnning 
>Jahia? If you run Jahia on top of Tomcat, why would you prefer a 
>commercial JMS server but are using an open source servlet container? And 
>you also have commercial companies supporting open source (JMS) 
>implementations (e.g. Jboss)?
>
>Else we may switch to JGroups in the near future for performance reasons 
>(at the place of JMS) so, make sure, if you do not take a low cost open 
>source solution, to verify that your commercial vendor also support JGoups 
>else you may loose your investment.
>
>Cheers,
>Stéphane
>
>At 14:19 02/05/2005, you wrote:
>
>Hi,
>Thank you for your answer and your experience with OpenJMS. Your answers 
>seem oriented on Open Source implementation. We are searching for a 
>commercial product with support.  Do you have any suggestions in this way?
>
>Thank again for your time.
>
>
>----------
>De : Stéphane Croisier [ mailto:[email protected]]
>Envoyé : 2 mai 2005 03:59
>À : [email protected]
>Objet : RE: Jahia Clustering - JMS
>
>Yes,
>
>We mainly tested it with OpenJMS but you may perfectly use any other open 
>source or commercial JMS implementation (e.g. for the open source ones: 
>http://www.manageability.org/blog/stuff/open-source-jms-java/view)
>
>Cheers
>Stéphane.
>
>At 01:40 02/05/2005, you wrote:
>
>Hi Douglas,
>
>We are currently in the middle of deploying a Jahia cluster using OpenJMS 
>( http://openjms.sourceforge.net/) as per the Jahia HOWTO on clustering.
>
>So far, it's working very well.
>
>One problem with OpenJMS: currently it does not support automatic failover 
>so without some other mechanism set up to allow for this it is not 
>possible to make a fully redundant cluster. OTOH, its purpose is to sync 
>the cache: therefore it is a necessary component to sync changes that are 
>made to the site. Changes to the site we are building will not happen 
>overnight or over the weekend so in practice we will always be able to fix 
>the JMS server before it becomes a problem with the live content.
>
>HTH,
>
>Chris