Thanks. -----Message d'origine----- De�: Serge Huber [mailto:[EMAIL PROTECTED] Envoy�: 2 juin 2005 08:54 ��: [email protected] Objet�: Re: Jahia Clustering - JMS
Hi Douglas, Regarding question 1 : this is exactly what Jahia does for the moment. All data synchronization goes through a JMS server. So you can use the redundancy of the JMS server implementation to make sure you won't loose a message. For question 2 : I would recommend a persistence configuration if it is absolutely needed and not too expensive in terms of performance. Jahia will send a *lot* of messages depending on the types of updates, so you will want to be sure that it is not too much of a CPU hog. Another way to insure consistency at all costs would be to completely deactivate all caching, but unless you have some VERY fast machines and databases, I wouldn't recommend this. Regards, Serge Huber. Douglas Doyer wrote: >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 >> >> >> > > > >
