You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Dominique Pfister (Created) (JIRA)" <ji...@apache.org> on 2011/11/07 11:17:51 UTC
[jira] [Created] (JCR-3138) Skip sync delay when changes are found
Skip sync delay when changes are found
--------------------------------------
Key: JCR-3138
URL: https://issues.apache.org/jira/browse/JCR-3138
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: clustering
Affects Versions: 2.3.2
Reporter: Dominique Pfister
Assignee: Dominique Pfister
The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Updated] (JCR-3138) Skip sync delay when changes are found
Posted by "Jukka Zitting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3138:
-------------------------------
Issue Type: Improvement (was: Bug)
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Fix For: 2.3.5
>
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Commented] (JCR-3138) Skip sync delay when changes are
found
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145341#comment-13145341 ]
Bart van der Schans commented on JCR-3138:
------------------------------------------
Hi Dominique,
Thanks for explaining. I've been working on JCR-2968 to get a similar setup (full replicas), but then through database replication. Maybe we should combine this issues with that one? I guess you're mostly looking for a "hook" to plugin your customized code?
Bart
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Commented] (JCR-3138) Skip sync delay when changes are
found
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145327#comment-13145327 ]
Bart van der Schans commented on JCR-3138:
------------------------------------------
Hi Dominique,
The "master" (although in a JR cluster all nodes are equal) writes it's changes to the database in a clustered setup. The slave queries the database (and not the JR node) for changes. So even when all other nodes are down the slave will just pull the changes from the database. As long as the database is running there is no riks of loosing data or endangering the integrity.
BTW, if you want to pull in changes on the slave you can do a Session.refresh(). This will force the ClusterNode to perform a sync().
Regards,
Bart
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Updated] (JCR-3138) Skip sync delay when changes are found
Posted by "Jukka Zitting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3138:
-------------------------------
Fix Version/s: 2.3.5
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Fix For: 2.3.5
>
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Resolved] (JCR-3138) Skip sync delay when changes are found
Posted by "Dominique Pfister (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister resolved JCR-3138.
------------------------------------
Resolution: Fixed
Implemented as optional behavior that can be switched on with a subclass overridable.
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Commented] (JCR-3138) Skip sync delay when changes are
found
Posted by "Dominique Pfister (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145335#comment-13145335 ]
Dominique Pfister commented on JCR-3138:
----------------------------------------
Hi Bart,
Thank you for your comment. You're absolutely right, in a standard cluster where the data itself is in shared storage such as a database, the slave will of course not talk to the master itself and the data does not get lost when the master crashes. We have a customized setup, however, where the data is not shared (every cluster node has a complete copy of the data) and where the slaves actually talk to the master: in order to support such a configuration, I'd like to make the sync loop more "customizable" by the actual journal implementation.
Kind regards
Dominique
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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
[jira] [Commented] (JCR-3138) Skip sync delay when changes are
found
Posted by "Dominique Pfister (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145556#comment-13145556 ]
Dominique Pfister commented on JCR-3138:
----------------------------------------
Hi Bart,
not quite: we already have our own journal implementation, derived from o.a.j.core.journal.AbstractJournal, and what I'd like to do now is break the body of doSync() into multiple steps that can be separately invoked by a subclass without having to resort to copy-paste. AFAICS, JCR-2968 is related to database journaling, whereas our implementation is not, so I don't think these two issues should be combined, what do you think?
Dominique
> Skip sync delay when changes are found
> --------------------------------------
>
> Key: JCR-3138
> URL: https://issues.apache.org/jira/browse/JCR-3138
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.3.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> The cluster synchronization on a slave does always wait for some time (as specified in the sync delay) before fetching changes. If a lot of changes are being written to the master, a slave will considerably fall behind the master in term of revisions, which may endanger the integrity of the cluster if the master will crash. I therefore suggest that a slave should rather immediately contact the master again after some changes have been found, until it sees no more changes.
--
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