In a Jahia cluster farm, information's that cannot be synchronized can
have repercussions. In such a context, I have two concerns:
1. Is this possible to have a redundancy for this synchronization?
The answer is yes with a JMS server in cluster.
2. How the synchronization is made in order to have the same
feeling of comfort for an update (compared to only one Jahia
server)? For example, do we use transactional messages,
persistence, etc,
Hi,
In reference to:
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.
The answer is excellent in a performance context only. We currently
use Jahia to allow our customers to enter themselves their
information. In certain cases, information not updated could have
political, legal and even financial repercussions.
In a context of only one Jahia server, the question was solved:
Of course, each time the content of a page is updated, the copy of the
concerned pages in
memory will be automatically flushed by the system. For example if you
change the title of the
home page, all the pages of your site will be automatically flushed as
all the navigation menu
will then become obsolete.
In a Jahia cluster farm, information's that cannot be synchronized can
have repercussions. In such a context, I have two concerns:
1. Is this possible to have a redundancy for this synchronization?
The answer is yes with a JMS server in cluster.
2. How the synchronization is made in order to have the same
feeling of comfort for an update (compared to only one Jahia
server)? For example, do we use transactional messages,
persistence, etc,
Thanks (This seems insane, but I must ask the question)
------------------------------------------------------------------------
*De :* St�phane Croisier [mailto:[EMAIL PROTECTED]
*Envoy� :* 2 mai 2005 11:07
*� :* [email protected]
*Objet :* 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
