[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050526#comment-13050526 ] Richard S. Hall commented on FELIX-3000: I was thinking something similar, but I was thinking about eliminating the callbacks object altogether. I just need to make sure it makes sense from a design and compliance perspective. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050564#comment-13050564 ] Felix Meschberger commented on FELIX-3000: -- @Callbacks: Yes, I didn't go the route of removing that. If I see it correctly, this has been introduced as a bridge for the ServiceRegistry to call the framework's private fireServiceEvent method, right ? Altough it looks a bit heavy-lifting it kind of makes sense (and probably also simplifies testing ?) @framework 4.0: what would be the timeframe for this ? We currently have this change under test and expect some results towards end of June at which time we would have to have a fix. I would like to prevent branching. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050565#comment-13050565 ] Richard S. Hall commented on FELIX-3000: Regarding Callbacks, original the service registry used a full-blown listener pattern, but this seemed overkill since the framework was the only listener, thus I replaced that with a single callbacks object. What we are essentially proposing is to remove any notion of events from the service registry and handle them completely externally. I think the tricky one is unregister. Regarding 4.0, I don't think it will be done until end of July at the earliest. Branching is not a big deal, really, we just create a branch from the 3.2.2 tag, apply the fix, do a release, remove the branch. So, if we have to go that route, then no big deal. It only becomes more difficult if there are a lot of other issues to port over from trunk to the branch...but we could only include this one issue. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050573#comment-13050573 ] Felix Meschberger commented on FELIX-3000: -- @Callbacks: Yes. BTW Just a nitpick, but I think the call to ((ServiceRegistrationImpl) reg).invalidate(); in the unregisterService(Bundle, ServiceReference) method needs not be in the synchronized(this) block. @4.0: Ok, thanks for the info. Lets pick this up again, when we need to ;-) Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
