jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-2968) Add an option to read the Clustering Journal from a different source than the rest of the clustering info
Date Tue, 11 Oct 2011 10:11:11 GMT

     [ https://issues.apache.org/jira/browse/JCR-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jukka Zitting updated JCR-2968:

    Fix Version/s:     (was: 2.3.1)

Bart, I like your idea in general as it's more flexible than the original one. Anyway, I'm
a bit concerned about essentially duplicating the entire journal configuration for the "slave

Since the only thing we're really overriding here is the handling of the local revision table
(and through that the janitor mechanism), I wonder if it would be cleaner to refactor the
relevant code out of the normal journal handling (sync, update, etc.) and add a separate configuration
mechanism for specifying how and where the local revision should be stored. If such configuration
is not present, we could for backwards compatibility fall back to the current behavior.

It seems like this still needs some thought, so unscheduling from 2.3.1.
> Add an option to read the Clustering Journal from a different source than the rest of
the clustering info
> ---------------------------------------------------------------------------------------------------------
>                 Key: JCR-2968
>                 URL: https://issues.apache.org/jira/browse/JCR-2968
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: clustering, jackrabbit-core
>    Affects Versions: 2.2.9
>            Reporter: Christian Stocker
>            Assignee: Jukka Zitting
>              Labels: patch
>         Attachments: 0001-JCR-2968-Add-an-option-to-read-the-Clustering-Journa.patch,
database-slave-local-revision-on-file.diff, patch_commit_2eed44310e71.patch
> This patch adds the possibility to read (but not write) the Cluster JOURNAL from a different
source than the rest of the cluster information. This makes it possible to setup a master/slave
DB setup, where everything cluster related is read from the slave, but writes to the master.
It reads the actual data also from the slave and assumes that this jackrabbit instance never
does any writes (except for updating the cluster index position in the DB). We have to read
the Cluster Journal from the slave to guarantee a consistent state
> More info why and how is here
> http://blog.liip.ch/archive/2011/05/04/how-to-make-jackrabbit-globally-distributable-fail-safe-and-scalable-in-one-go.html
> I didn't write any tests yet, if you can point me, where I should add them, I'll gladly
do them.
> Would be great, if we could integrate that in any of the future Jackrabbit releases.
> It's of course fully backwards compatible, nothing changes, if you don't sepcify 
>  <param name="dataSourceNameJournalRead">
> in repository.xml

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message