You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2009/07/09 10:26:14 UTC
[jira] Created: (SLING-1040) Too much synchronization in
QuartzScheduler?
Too much synchronization in QuartzScheduler?
--------------------------------------------
Key: SLING-1040
URL: https://issues.apache.org/jira/browse/SLING-1040
Project: Sling
Issue Type: Bug
Affects Versions: Commons Scheduler 2.0.4
Reporter: Bertrand Delacretaz
Priority: Minor
In one of my jcrinstall tests I got a deadlock when jcrinstall tried to stop the org.apache.sling.commons.scheduler bundle while it was being started by the Felix ComponentActorThread.
I'll attach the deadlock stack trace - wondering if some of the synchronized sections in QuartzScheduler could be removed, to avoid such issues.
That might be a jcrinstall/Felix problem as well: stopping a bundle while it is being activated doesn't sound right, but I'm not sure how to prevent this, as the ComponentActorThread actions run asynchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1040) Too much synchronization in
QuartzScheduler?
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729109#action_12729109 ]
Bertrand Delacretaz commented on SLING-1040:
--------------------------------------------
Right - I guess the problematic section is
protected void activate(ComponentContext ctx) throws Exception {
this.context = ctx;
synchronized ( this.registeredJobs ) {
this.init();
for( Object[] arr : this.registeredJobs ) {
try {
this.register((String)arr[0], (ServiceReference)arr[1]);
The lock should be released before calling this.register(...)
That code was written by Carsten, so I'll let him have a look instead of messing with it ;-)
> Too much synchronization in QuartzScheduler?
> --------------------------------------------
>
> Key: SLING-1040
> URL: https://issues.apache.org/jira/browse/SLING-1040
> Project: Sling
> Issue Type: Bug
> Affects Versions: Commons Scheduler 2.0.4
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: deadlock-trace.txt
>
>
> In one of my jcrinstall tests I got a deadlock when jcrinstall tried to stop the org.apache.sling.commons.scheduler bundle while it was being started by the Felix ComponentActorThread.
> I'll attach the deadlock stack trace - wondering if some of the synchronized sections in QuartzScheduler could be removed, to avoid such issues.
> That might be a jcrinstall/Felix problem as well: stopping a bundle while it is being activated doesn't sound right, but I'm not sure how to prevent this, as the ComponentActorThread actions run asynchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1040) Too much synchronization in
QuartzScheduler?
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated SLING-1040:
---------------------------------------
Attachment: deadlock-trace.txt
> Too much synchronization in QuartzScheduler?
> --------------------------------------------
>
> Key: SLING-1040
> URL: https://issues.apache.org/jira/browse/SLING-1040
> Project: Sling
> Issue Type: Bug
> Affects Versions: Commons Scheduler 2.0.4
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: deadlock-trace.txt
>
>
> In one of my jcrinstall tests I got a deadlock when jcrinstall tried to stop the org.apache.sling.commons.scheduler bundle while it was being started by the Felix ComponentActorThread.
> I'll attach the deadlock stack trace - wondering if some of the synchronized sections in QuartzScheduler could be removed, to avoid such issues.
> That might be a jcrinstall/Felix problem as well: stopping a bundle while it is being activated doesn't sound right, but I'm not sure how to prevent this, as the ComponentActorThread actions run asynchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1040) Too much synchronization in
QuartzScheduler?
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler reassigned SLING-1040:
---------------------------------------
Assignee: Carsten Ziegeler
> Too much synchronization in QuartzScheduler?
> --------------------------------------------
>
> Key: SLING-1040
> URL: https://issues.apache.org/jira/browse/SLING-1040
> Project: Sling
> Issue Type: Bug
> Affects Versions: Commons Scheduler 2.0.4
> Reporter: Bertrand Delacretaz
> Assignee: Carsten Ziegeler
> Priority: Minor
> Attachments: deadlock-trace.txt
>
>
> In one of my jcrinstall tests I got a deadlock when jcrinstall tried to stop the org.apache.sling.commons.scheduler bundle while it was being started by the Felix ComponentActorThread.
> I'll attach the deadlock stack trace - wondering if some of the synchronized sections in QuartzScheduler could be removed, to avoid such issues.
> That might be a jcrinstall/Felix problem as well: stopping a bundle while it is being activated doesn't sound right, but I'm not sure how to prevent this, as the ComponentActorThread actions run asynchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1040) Too much synchronization in
QuartzScheduler?
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729107#action_12729107 ]
Felix Meschberger commented on SLING-1040:
------------------------------------------
It looks like the QuartzScheduler is holding a lock on an Array Liste while calling into the framework. Probably the lock should be released before calling into the framework (caveat: not looking at the code, just the stacktrace)
> Too much synchronization in QuartzScheduler?
> --------------------------------------------
>
> Key: SLING-1040
> URL: https://issues.apache.org/jira/browse/SLING-1040
> Project: Sling
> Issue Type: Bug
> Affects Versions: Commons Scheduler 2.0.4
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: deadlock-trace.txt
>
>
> In one of my jcrinstall tests I got a deadlock when jcrinstall tried to stop the org.apache.sling.commons.scheduler bundle while it was being started by the Felix ComponentActorThread.
> I'll attach the deadlock stack trace - wondering if some of the synchronized sections in QuartzScheduler could be removed, to avoid such issues.
> That might be a jcrinstall/Felix problem as well: stopping a bundle while it is being activated doesn't sound right, but I'm not sure how to prevent this, as the ComponentActorThread actions run asynchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1040) Too much synchronization in
QuartzScheduler?
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler closed SLING-1040.
-----------------------------------
Resolution: Fixed
Fix Version/s: Commons Scheduler 2.0.6
The synchronization was way to aggressive and has been introduced by SLING-984; I'Ve cleaned it up now to a minimum and also fixed some other minor issues in revision: 792809
> Too much synchronization in QuartzScheduler?
> --------------------------------------------
>
> Key: SLING-1040
> URL: https://issues.apache.org/jira/browse/SLING-1040
> Project: Sling
> Issue Type: Bug
> Affects Versions: Commons Scheduler 2.0.4
> Reporter: Bertrand Delacretaz
> Assignee: Carsten Ziegeler
> Priority: Minor
> Fix For: Commons Scheduler 2.0.6
>
> Attachments: deadlock-trace.txt
>
>
> In one of my jcrinstall tests I got a deadlock when jcrinstall tried to stop the org.apache.sling.commons.scheduler bundle while it was being started by the Felix ComponentActorThread.
> I'll attach the deadlock stack trace - wondering if some of the synchronized sections in QuartzScheduler could be removed, to avoid such issues.
> That might be a jcrinstall/Felix problem as well: stopping a bundle while it is being activated doesn't sound right, but I'm not sure how to prevent this, as the ComponentActorThread actions run asynchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.