Hi Serge,
I understand the orientation of Jahia. But right now, I must set up a
more robust solution in our organization and we must discuss of the current
version available for Jahia 4.05, 4.06 or 4.1.
The question remains:
> 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.
-----Message d'origine-----
De�: Serge Huber [mailto:[EMAIL PROTECTED]
Envoy�: 13 mai 2005 04:57
��: [email protected]
Objet�: Re: Jahia Clustering - JMS
Hi Douglas,
Sorry I couldn't get into this interesting thread earlier as I was away
on vacation.
Currently JMS is used only as a cache synchronization mechanism in
Jahia. The contents of the cached entries are sent through to the other
nodes, in order to provide a performant cache replication. St�phane
mentioned that we would remove the JMS communication mechanism to
replace it with JGroups, which is what we intend to do. Actually there
are a few things to be aware of regarding this change :
- JGroups is a clustering abstraction layer, that DOES support JMS
messaging, along with other setups. We are talking about giving more
choices at deployment onto which configuration users want. We are not
removing the option of going through a JMS server.
- At the same time we want to make the cache implementation pluggeable,
so that other cache implementation can replace the one in Jahia, such as
for example OSCache (that support clustering by also using JGroups), or
maybe even commercial ones such as Tangosol.
So basically what we are looking at in these changes is offering more
flexibility in terms of clustering configuration, as well as keeping the
good performance that we are seeing when hitting cached entries.
Best regards,
Serge Huber.
Douglas Doyer wrote:
> 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
>
