Thanks for your answer (very
appreciate).
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
