You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Mete Atamel (JIRA)" <ji...@apache.org> on 2012/05/09 16:43:49 UTC
[jira] [Created] (JCR-3303) ClusterNode's stopDelay should default
to something other zero
Mete Atamel created JCR-3303:
--------------------------------
Summary: ClusterNode's stopDelay should default to something other zero
Key: JCR-3303
URL: https://issues.apache.org/jira/browse/JCR-3303
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Reporter: Mete Atamel
Priority: Minor
ClusterNode has a stopDelay that defaults to zero. This is problematic because it's used in joining syncThread. SyncThread is supposed to be a daemon thread which means it's not supposed to block JVM shutdown. However, by joining syncThread with a default stopDelay of zero, ClusterNode can potentially wait for syncThread to finish its job forever. This effectively makes syncThread a non-daemon thread and that can definitely make ClusterNode#stop block forever if syncThread never finishes.
Instead of defaulting to zero, I think it'd be better if stopDelay defaulted to something more reasonable like 2 * syncDelay. There's no need to make ClusterNode block forever for sync in any case.
--
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-3303) ClusterNode's stopDelay should default
to something other zero
Posted by "Mete Atamel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mete Atamel updated JCR-3303:
-----------------------------
Fix Version/s: 2.4.1
Affects Version/s: 2.4.1
Status: Patch Available (was: Open)
> ClusterNode's stopDelay should default to something other zero
> --------------------------------------------------------------
>
> Key: JCR-3303
> URL: https://issues.apache.org/jira/browse/JCR-3303
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.4.1
> Reporter: Mete Atamel
> Priority: Minor
> Fix For: 2.4.1
>
> Attachments: JCR-3303.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> ClusterNode has a stopDelay that defaults to zero. This is problematic because it's used in joining syncThread. SyncThread is supposed to be a daemon thread which means it's not supposed to block JVM shutdown. However, by joining syncThread with a default stopDelay of zero, ClusterNode can potentially wait for syncThread to finish its job forever. This effectively makes syncThread a non-daemon thread and that can definitely make ClusterNode#stop block forever if syncThread never finishes.
> Instead of defaulting to zero, I think it'd be better if stopDelay defaulted to something more reasonable like 2 * syncDelay. There's no need to make ClusterNode block forever for sync in any case.
--
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-3303) ClusterNode's stopDelay should
default to something other zero
Posted by "Bart van der Schans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290099#comment-13290099 ]
Bart van der Schans commented on JCR-3303:
------------------------------------------
Merged in 2.4 in 1346853.
> ClusterNode's stopDelay should default to something other zero
> --------------------------------------------------------------
>
> Key: JCR-3303
> URL: https://issues.apache.org/jira/browse/JCR-3303
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.4.1
> Reporter: Mete Atamel
> Priority: Minor
> Fix For: 2.5
>
> Attachments: JCR-3303.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> ClusterNode has a stopDelay that defaults to zero. This is problematic because it's used in joining syncThread. SyncThread is supposed to be a daemon thread which means it's not supposed to block JVM shutdown. However, by joining syncThread with a default stopDelay of zero, ClusterNode can potentially wait for syncThread to finish its job forever. This effectively makes syncThread a non-daemon thread and that can definitely make ClusterNode#stop block forever if syncThread never finishes.
> Instead of defaulting to zero, I think it'd be better if stopDelay defaulted to something more reasonable like 2 * syncDelay. There's no need to make ClusterNode block forever for sync in any case.
--
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-3303) ClusterNode's stopDelay should default
to something other zero
Posted by "Mete Atamel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mete Atamel updated JCR-3303:
-----------------------------
Attachment: JCR-3303.patch
Patch against JR/trunk
> ClusterNode's stopDelay should default to something other zero
> --------------------------------------------------------------
>
> Key: JCR-3303
> URL: https://issues.apache.org/jira/browse/JCR-3303
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.4.1
> Reporter: Mete Atamel
> Priority: Minor
> Fix For: 2.4.1
>
> Attachments: JCR-3303.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> ClusterNode has a stopDelay that defaults to zero. This is problematic because it's used in joining syncThread. SyncThread is supposed to be a daemon thread which means it's not supposed to block JVM shutdown. However, by joining syncThread with a default stopDelay of zero, ClusterNode can potentially wait for syncThread to finish its job forever. This effectively makes syncThread a non-daemon thread and that can definitely make ClusterNode#stop block forever if syncThread never finishes.
> Instead of defaulting to zero, I think it'd be better if stopDelay defaulted to something more reasonable like 2 * syncDelay. There's no need to make ClusterNode block forever for sync in any case.
--
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-3303) ClusterNode's stopDelay should default
to something other zero
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-3303:
----------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.4.1)
2.5
Status: Resolved (was: Patch Available)
Thanks for the patch.
Looks very reasonable. Applied in revision: 1336252
> ClusterNode's stopDelay should default to something other zero
> --------------------------------------------------------------
>
> Key: JCR-3303
> URL: https://issues.apache.org/jira/browse/JCR-3303
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.4.1
> Reporter: Mete Atamel
> Priority: Minor
> Fix For: 2.5
>
> Attachments: JCR-3303.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> ClusterNode has a stopDelay that defaults to zero. This is problematic because it's used in joining syncThread. SyncThread is supposed to be a daemon thread which means it's not supposed to block JVM shutdown. However, by joining syncThread with a default stopDelay of zero, ClusterNode can potentially wait for syncThread to finish its job forever. This effectively makes syncThread a non-daemon thread and that can definitely make ClusterNode#stop block forever if syncThread never finishes.
> Instead of defaulting to zero, I think it'd be better if stopDelay defaulted to something more reasonable like 2 * syncDelay. There's no need to make ClusterNode block forever for sync in any case.
--
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-3303) ClusterNode's stopDelay should default
to something other zero
Posted by "Bart van der Schans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart van der Schans updated JCR-3303:
-------------------------------------
Fix Version/s: 2.4.2
2.2.13
> ClusterNode's stopDelay should default to something other zero
> --------------------------------------------------------------
>
> Key: JCR-3303
> URL: https://issues.apache.org/jira/browse/JCR-3303
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.4.1
> Reporter: Mete Atamel
> Priority: Minor
> Fix For: 2.2.13, 2.4.2, 2.5
>
> Attachments: JCR-3303.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> ClusterNode has a stopDelay that defaults to zero. This is problematic because it's used in joining syncThread. SyncThread is supposed to be a daemon thread which means it's not supposed to block JVM shutdown. However, by joining syncThread with a default stopDelay of zero, ClusterNode can potentially wait for syncThread to finish its job forever. This effectively makes syncThread a non-daemon thread and that can definitely make ClusterNode#stop block forever if syncThread never finishes.
> Instead of defaulting to zero, I think it'd be better if stopDelay defaulted to something more reasonable like 2 * syncDelay. There's no need to make ClusterNode block forever for sync in any case.
--
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