Re: New feature: Clustering
On 11/10/06, Ian Boston <[EMAIL PROTECTED]> wrote: Will it be possible to replace FileJournal with something more message oriented ? eg JGroups or ActiveMQ (JMS Topic) Yes, you can replace the FileJournal with another implementation of the o.a.j.core.cluster.Journal interface that serializes/deserializes item state operations and events into/from some kind of javax.jms.Message and uses JMS as transport system. Dominique
Re: New feature: Clustering
Will it be possible to replace FileJournal with something more message oriented ? eg JGroups or ActiveMQ (JMS Topic) This is to make the cache invalidation a real event rather than a poll, and to make the propagation fast. I believe that you can configure AMQ to manage the persistence of topics in various ways so it may cover the outstanding issues you have with Journal management. just a thought. Ian (BTW, thanks for you comments on what type of cluster... all makes sense and fits our situation (www.sakaiproject.org) ) Dominique Pfister wrote: Hi, I just committed some files to implement a first approach to clustering in jackrabbit. Inside this approach, all repositories in the cluster share the persistence layer (e.g. a derby database started standalone). When a repository commits some changes, it will write a log record to a shared "journal" directory. Another repository watching that directory will eventually read this record, invalidate its internal caches and fire corresponding events. In order to enable clustering on some repositories, do the following for each repository: (1) Configure persistence managers with sharable data sources, e.g. standalone databases instead of embedded ones (2) Add a configuration entry to the end of your repository's repository.xml: This will make the repository write changes to the directory "/mnt/journal" and read changes made by others in the cluster. Make sure that every repository will get a different value for the "id" attribute. Alternatively, you may set the system property named "org.apache.jackrabbit.core.cluster.node_id" to your preferred value. Features still missing in the current implementation are: - Automatic archival of journal log entries to save space - Using a database as backend for the journal - And probably a lot more... The status of those features can be tracked here: https://issues.apache.org/jira/browse/JCR-623 Kind regards Dominique Pfister
Re: New feature: Clustering
On 11/6/06, Cédric Damioli <[EMAIL PROTECTED]> wrote: More than clustering, does this approach also enable a new PM-based implementation of the Model 3 deployment, ie a remote, shareable PM, accessible from various Jackrabbit instances ? I know this is not the purpose of a PM, but with this proposed architecture, results are functionnally the same, aren't they ? Yes, they are. It is conceivable that such a PM could essentially add an entry to the journal to inform clients about the external change. On the other side, technically, journal entries contain not only the items that changed but also the events they generate, which is out of a PM's scope. Regards Dominique
Re: New feature: Clustering
Dominique Pfister a écrit : Hi, I just committed some files to implement a first approach to clustering in jackrabbit. Inside this approach, all repositories in the cluster share the persistence layer (e.g. a derby database started standalone). When a repository commits some changes, it will write a log record to a shared "journal" directory. Another repository watching that directory will eventually read this record, invalidate its internal caches and fire corresponding events. More than clustering, does this approach also enable a new PM-based implementation of the Model 3 deployment, ie a remote, shareable PM, accessible from various Jackrabbit instances ? I know this is not the purpose of a PM, but with this proposed architecture, results are functionnally the same, aren't they ? I also guess that this approach will be way faster than the RMI one, even if it's not its primary goal. Regards, -- Cédric Damioli Directeur de projets Solutions CMS ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
New feature: Clustering
Hi, I just committed some files to implement a first approach to clustering in jackrabbit. Inside this approach, all repositories in the cluster share the persistence layer (e.g. a derby database started standalone). When a repository commits some changes, it will write a log record to a shared "journal" directory. Another repository watching that directory will eventually read this record, invalidate its internal caches and fire corresponding events. In order to enable clustering on some repositories, do the following for each repository: (1) Configure persistence managers with sharable data sources, e.g. standalone databases instead of embedded ones (2) Add a configuration entry to the end of your repository's repository.xml: This will make the repository write changes to the directory "/mnt/journal" and read changes made by others in the cluster. Make sure that every repository will get a different value for the "id" attribute. Alternatively, you may set the system property named "org.apache.jackrabbit.core.cluster.node_id" to your preferred value. Features still missing in the current implementation are: - Automatic archival of journal log entries to save space - Using a database as backend for the journal - And probably a lot more... The status of those features can be tracked here: https://issues.apache.org/jira/browse/JCR-623 Kind regards Dominique Pfister
