Re: SCR could not obtain state lock after 5 seconds
OK, I went ahead and committed a bunch of work including a revised locking scheme (which has been in a patch to FELIX-3456 for a couple months) and the new attempt to track how locks are obtained and do a thread dump when a lock problem occurs. I haven't been able to actually generate a lock problem to see if the logging code works The timeout should definitely be configurable, I'll try to get to that soon. Let me know if this causes problems!!! thanks david jencks On Aug 9, 2012, at 10:27 AM, Pierre De Rop wrote: > Hi David; > > It's also my case, I see the problem only occasionally, in some automatic > tests, where many JVM might be starting concurrently, on the same host. > > So, yes, If you commit the improved code, I could then retry my automatic > tests, to see if we find something. > What is the improved code exactly ? > > Anyway, from my side, I have increased the state lock timeout to 60 > seconds, to see if the problem disappear. > ... don't you think that this timeout should be configurable, instead of > using 5 seconds by default ? > > regards; > /Pierre > > On Thu, Aug 9, 2012 at 4:09 PM, David Jencks wrote: > >> I've been wondering if trunk code would show these deadlocks I have >> some improved code in a jira and occasionally it also seems to show this >> problem. (I've personally never seen it locally, it shows up occasionally >> in automated builds at work) I've added some more stuff that ought to log >> appropriate info when this occurs, so since this has shown up "in the wild" >> I'm very tempted to commit the improved code and the (probably temporary) >> extra logging. >> >> Any objections? >> >> thanks >> david jencks >> >> On Aug 9, 2012, at 8:46 AM, Pierre De Rop wrote: >> >>> Hi everyone, >>> >>> I'm getting a "Could not obtain lock" exception from SCR. This exception >> is >>> thrown when SCR can't aquire its internal stack lock after 5 seconds. >>> For now, I don't know if I am facing a bug from SCR, or if I'm just in a >>> temporary situation where my JVM runs slowly (because of another process >>> which might consumes all CPUs temporarily). >>> >>> However, I provide here the exception, as well as a full dump stack >> trace, >>> in case you find out a possible deadlock from SCR ? >>> (I'm using SCR from trunk, and Framework 4.0.3): >>> >>> java.lang.IllegalStateException: Could not obtain lock >>> at >>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainStateLock(AbstractComponentManager.java:161) >>> at >>> >> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:158) >>> at >>> >> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >>> at >>> >> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) >>> at >>> >> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) >>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) >>> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) >>> at >>> >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) >>> at >>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:603) >>> at >>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:626) >>> at >>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1253) >>> at >>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:508) >>> at >>> >> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:291) >>> at >>> >> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:171) >>> at >>> >> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >>> at >>> >> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) >>> at >>> >> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) >>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) >>> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) >>> at >>> >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) >>> at >>> >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320) >>> at com.nextenso.agent.Agent.initSuperAgent(Agent.java:715) >>> at com.nextenso.agent.Agent._activate(Agent.java:646) >>> at com.nextenso.agent.Agent.access$100(Agent.java:92) >>> at com.nextenso.agent.Agent$5.run(Agent.java:365) >>> at >>> >> com.alcatel.as.service.concurrent.SerialExecutor.execute(S
[jira] [Created] (FELIX-3625) "officially" upgrade scr to ds 1.2 from compendium 4.3
David Jencks created FELIX-3625: --- Summary: "officially" upgrade scr to ds 1.2 from compendium 4.3 Key: FELIX-3625 URL: https://issues.apache.org/jira/browse/FELIX-3625 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.8.0 Reporter: David Jencks Fix For: scr-1.8.0 There aren't any api changes to ds 1.2 but there is a new schema, since we support ds 1.2 we should use the right versions. -- 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] [Assigned] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned FELIX-3456: --- Assignee: David Jencks > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Assignee: David Jencks >Priority: Critical > Fix For: scr-1.6.2 > > Attachments: FELIX-3456-1.1.diff, FELIX-3456-1.diff, > FELIX-3456-3.diff, FELIX-3456-4.diff, FELIX-3456-5.diff, FELIX-3456-5a.diff, > FELIX-3456-5b.diff, FELIX-3456-7.diff, FELIX-3456-7a.diff, FELIX-3456-8.diff, > FELIX-3456-8a.diff, FELIX-3456-fmeschbe-6.patch, FELIX-3456-fmeschbe.patch > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > this issue? > Thanks -- 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
Re: [VOTE] Accept the (slightly modified) UserAdmin donation by Jan Willem Janssen
+1 Regards Felix Am 09.08.2012 um 13:55 schrieb Marcel Offermans: > +1 > > ...and thanks for explaining what happened, Jan Willem! >
Re: SCR could not obtain state lock after 5 seconds
Hi David; It's also my case, I see the problem only occasionally, in some automatic tests, where many JVM might be starting concurrently, on the same host. So, yes, If you commit the improved code, I could then retry my automatic tests, to see if we find something. What is the improved code exactly ? Anyway, from my side, I have increased the state lock timeout to 60 seconds, to see if the problem disappear. ... don't you think that this timeout should be configurable, instead of using 5 seconds by default ? regards; /Pierre On Thu, Aug 9, 2012 at 4:09 PM, David Jencks wrote: > I've been wondering if trunk code would show these deadlocks I have > some improved code in a jira and occasionally it also seems to show this > problem. (I've personally never seen it locally, it shows up occasionally > in automated builds at work) I've added some more stuff that ought to log > appropriate info when this occurs, so since this has shown up "in the wild" > I'm very tempted to commit the improved code and the (probably temporary) > extra logging. > > Any objections? > > thanks > david jencks > > On Aug 9, 2012, at 8:46 AM, Pierre De Rop wrote: > > > Hi everyone, > > > > I'm getting a "Could not obtain lock" exception from SCR. This exception > is > > thrown when SCR can't aquire its internal stack lock after 5 seconds. > > For now, I don't know if I am facing a bug from SCR, or if I'm just in a > > temporary situation where my JVM runs slowly (because of another process > > which might consumes all CPUs temporarily). > > > > However, I provide here the exception, as well as a full dump stack > trace, > > in case you find out a possible deadlock from SCR ? > > (I'm using SCR from trunk, and Framework 4.0.3): > > > > java.lang.IllegalStateException: Could not obtain lock > >at > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainStateLock(AbstractComponentManager.java:161) > >at > > > org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:158) > >at > > > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > >at > > > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > >at > > > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > >at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) > >at org.apache.felix.framework.Felix.registerService(Felix.java:3275) > >at > > > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) > >at > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:603) > >at > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:626) > >at > > > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1253) > >at > > > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:508) > >at > > > org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:291) > >at > > > org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:171) > >at > > > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > >at > > > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > >at > > > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > >at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) > >at org.apache.felix.framework.Felix.registerService(Felix.java:3275) > >at > > > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) > >at > > > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320) > >at com.nextenso.agent.Agent.initSuperAgent(Agent.java:715) > >at com.nextenso.agent.Agent._activate(Agent.java:646) > >at com.nextenso.agent.Agent.access$100(Agent.java:92) > >at com.nextenso.agent.Agent$5.run(Agent.java:365) > >at > > > com.alcatel.as.service.concurrent.SerialExecutor.execute(SerialExecutor.java:41) > >at com.nextenso.agent.Agent.bindSessionManager(Agent.java:362) > >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > >at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >at java.lang.reflect.Method.invoke(Method.java:616) > >at > > > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:226) > >at > > > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) > >
Re: SCR could not obtain state lock after 5 seconds
Hi Am 09.08.2012 um 16:09 schrieb David Jencks: > I've been wondering if trunk code would show these deadlocks I have some > improved code in a jira and occasionally it also seems to show this problem. > (I've personally never seen it locally, it shows up occasionally in automated > builds at work) I've added some more stuff that ought to log appropriate > info when this occurs, so since this has shown up "in the wild" I'm very > tempted to commit the improved code and the (probably temporary) extra > logging. +1 to extra logging (thread dump sounds interesting in case of potential deadlocks) What improved code are you referring to ? Basically I am +1 to add improved code. Thanks. Regards Felix > > Any objections? > > thanks > david jencks > > On Aug 9, 2012, at 8:46 AM, Pierre De Rop wrote: > >> Hi everyone, >> >> I'm getting a "Could not obtain lock" exception from SCR. This exception is >> thrown when SCR can't aquire its internal stack lock after 5 seconds. >> For now, I don't know if I am facing a bug from SCR, or if I'm just in a >> temporary situation where my JVM runs slowly (because of another process >> which might consumes all CPUs temporarily). >> >> However, I provide here the exception, as well as a full dump stack trace, >> in case you find out a possible deadlock from SCR ? >> (I'm using SCR from trunk, and Framework 4.0.3): >> >> java.lang.IllegalStateException: Could not obtain lock >> at >> org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainStateLock(AbstractComponentManager.java:161) >> at >> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:158) >> at >> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >> at >> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) >> at >> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) >> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) >> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) >> at >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) >> at >> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:603) >> at >> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:626) >> at >> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1253) >> at >> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:508) >> at >> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:291) >> at >> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:171) >> at >> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >> at >> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) >> at >> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) >> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) >> at org.apache.felix.framework.Felix.registerService(Felix.java:3275) >> at >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) >> at >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320) >> at com.nextenso.agent.Agent.initSuperAgent(Agent.java:715) >> at com.nextenso.agent.Agent._activate(Agent.java:646) >> at com.nextenso.agent.Agent.access$100(Agent.java:92) >> at com.nextenso.agent.Agent$5.run(Agent.java:365) >> at >> com.alcatel.as.service.concurrent.SerialExecutor.execute(SerialExecutor.java:41) >> at com.nextenso.agent.Agent.bindSessionManager(Agent.java:362) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:616) >> at >> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:226) >> at >> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) >> at >> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:603) >> at >> org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.invoke(BaseMethod.java:560) >> at >> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:484) >> at >> org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:1084) >> at >> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:326) >> at >
Re: SCR could not obtain state lock after 5 seconds
I've been wondering if trunk code would show these deadlocks I have some improved code in a jira and occasionally it also seems to show this problem. (I've personally never seen it locally, it shows up occasionally in automated builds at work) I've added some more stuff that ought to log appropriate info when this occurs, so since this has shown up "in the wild" I'm very tempted to commit the improved code and the (probably temporary) extra logging. Any objections? thanks david jencks On Aug 9, 2012, at 8:46 AM, Pierre De Rop wrote: > Hi everyone, > > I'm getting a "Could not obtain lock" exception from SCR. This exception is > thrown when SCR can't aquire its internal stack lock after 5 seconds. > For now, I don't know if I am facing a bug from SCR, or if I'm just in a > temporary situation where my JVM runs slowly (because of another process > which might consumes all CPUs temporarily). > > However, I provide here the exception, as well as a full dump stack trace, > in case you find out a possible deadlock from SCR ? > (I'm using SCR from trunk, and Framework 4.0.3): > > java.lang.IllegalStateException: Could not obtain lock >at > org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainStateLock(AbstractComponentManager.java:161) >at > org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:158) >at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) >at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) >at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) >at org.apache.felix.framework.Felix.registerService(Felix.java:3275) >at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) >at > org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:603) >at > org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:626) >at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1253) >at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:508) >at > org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:291) >at > org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:171) >at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) >at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) >at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) >at org.apache.felix.framework.Felix.registerService(Felix.java:3275) >at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) >at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320) >at com.nextenso.agent.Agent.initSuperAgent(Agent.java:715) >at com.nextenso.agent.Agent._activate(Agent.java:646) >at com.nextenso.agent.Agent.access$100(Agent.java:92) >at com.nextenso.agent.Agent$5.run(Agent.java:365) >at > com.alcatel.as.service.concurrent.SerialExecutor.execute(SerialExecutor.java:41) >at com.nextenso.agent.Agent.bindSessionManager(Agent.java:362) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:616) >at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:226) >at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) >at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:603) >at > org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.invoke(BaseMethod.java:560) >at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:484) >at > org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:1084) >at > org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:326) >at > org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:171) >at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) >at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.jav
Re: [VOTE] Accept the (slightly modified) UserAdmin donation by Jan Willem Janssen
+1 regards, Karl p.s.: /me thinks this could have been a lazy consensus vote - we start to look like a facebook with javascript turned off ;-) On Thu, Aug 9, 2012 at 4:03 PM, Richard S. Hall wrote: > +1 > > -> richard > > On Aug 9, 2012, at 02:50 , Marcel Offermans > wrote: > >> Since Jan Willem updated the issue [1] after we held the vote, we >> technically did not vote on the contribution that will end up in subversion, >> as Richard pointed out in that issue. Therefore, although probably a >> formality, we do need to revote on this new version so it aligns with the >> data we provide in the IP clearance process. So could you all please vote >> again after looking at those changes: >> >> [ ] +1 Accept this donation. >> [ ] 0 Don't care. >> [ ] -1 Don't accept this donation (please motivate your vote). >> >> Greetings, Marcel >> >> [1] https://issues.apache.org/jira/browse/FELIX-3600 > -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
Re: [VOTE] Accept the (slightly modified) UserAdmin donation by Jan Willem Janssen
+1 -> richard On Aug 9, 2012, at 02:50 , Marcel Offermans wrote: > Since Jan Willem updated the issue [1] after we held the vote, we technically > did not vote on the contribution that will end up in subversion, as Richard > pointed out in that issue. Therefore, although probably a formality, we do > need to revote on this new version so it aligns with the data we provide in > the IP clearance process. So could you all please vote again after looking at > those changes: > > [ ] +1 Accept this donation. > [ ] 0 Don't care. > [ ] -1 Don't accept this donation (please motivate your vote). > > Greetings, Marcel > > [1] https://issues.apache.org/jira/browse/FELIX-3600
[jira] [Commented] (FELIX-3624) Performance tuning solution for BundleRepository/ResolverImpl
[
https://issues.apache.org/jira/browse/FELIX-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431806#comment-13431806
]
Richard S. Hall commented on FELIX-3624:
Thanks for looking into this.
I am hopeful that eventually we will address some of these issues by
re-implementing OBR using the new resolver subproject and then we could use the
capability indexing approach of the framework to speed up matching too.
> Performance tuning solution for BundleRepository/ResolverImpl
> -
>
> Key: FELIX-3624
> URL: https://issues.apache.org/jira/browse/FELIX-3624
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
> Environment: Geronimo3 + BundleRepository 1.6.6
>Reporter: SheldonShao
>Priority: Critical
> Attachments: Felix_ResolverImpl.png,
> Felix_ResolverImpl_AfterTuning.png, ResolverImpl.java
>
>
> There are too many numebers of method calling about checking whether
> capabities are matched with requiment in ResolverImpl.searchResources.
> This is a performance issue of ResolverImpl.resolve.
> If it creates a capabity to resource+capabity mapping first. Then leverage
> this cache to do requirment matching. It will get better performance.
> Here is part of code. More details please check attachments.
> private final Map m_capabilitiesCache = new HashMap(8192);
> private String getKey(String filter, String prefix) {
> if (filter != null) {
> int index = filter.indexOf(prefix);
> if (index > 0) {
> int end = filter.indexOf(SUFFIX, index +
> prefix.length());
> if (end > index) {
> return filter.substring(index, end);
> }
> }
> }
> return null;
> }
> private String getKey(Requirement requirement) {
> String key = null;
> String name = requirement.getName();
> String filter = requirement.getFilter();
> if (Capability.BUNDLE.equals(name)) {
> key = getKey(filter, PREFIX_SYMBOLICNAME);
> } else if (Capability.PACKAGE.equals(name)) {
> key = getKey(filter, PREFIX_PACKAGE);
> } else if (Capability.SERVICE.equals(name)) {
> key = getKey(filter, PREFIX_SERVICE);
> } else if (Capability.FRAGMENT.equals(name)) {
> key = getKey(filter, PREFIX_HOST);
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> return key;
> }
> private static final String PREFIX_SYMBOLICNAME = "symbolicname=";
> private static final String PREFIX_PACKAGE = "package=";
> private static final String PREFIX_SERVICE = "service=";
> private static final String PREFIX_HOST = "host=";
> private static final String PREFIX_CAPABILITY = "capability=";
> private static final char SUFFIX = ')';
> private void initCache(Capability[] capabilities, Resource resource) {
> Capability cap;
> Map properties;
> String name;
> for (int j = 0; j < capabilities.length; j++) {
> cap = capabilities[j];
> String key = null;
> properties = cap.getPropertiesAsMap();
> name = cap.getName();
> if (Capability.BUNDLE.equals(name)) {
> key = PREFIX_SYMBOLICNAME +
> properties.get("symbolicname");
> } else if (Capability.PACKAGE.equals(name)) {
> key = PREFIX_PACKAGE +
> properties.get("package");
> } else if (Capability.SERVICE.equals(name)) {
> key = PREFIX_SERVICE +
> properties.get("service");
> } else if (Capability.FRAGMENT.equals(name)) {
> key = PREFIX_HOST + properties.get("host");
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> List caps = (List) m_capabilitiesCache.get(key);
> if (caps == null) {
> caps = new ArrayList(2);
> m_capabilitiesCache.put(key, caps);
> }
> caps.add(new ResourceCapabilityImpl(resource, cap));
> }
> }
> private void initCache(Resource[] locals) {
> Resource resource;
> for (in
[jira] [Commented] (FELIX-3624) Performance tuning solution for BundleRepository/ResolverImpl
[
https://issues.apache.org/jira/browse/FELIX-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431757#comment-13431757
]
SheldonShao commented on FELIX-3624:
I am new for this. I will check "Grant license to ASF for inclusion in ASF
works" later.
And also I am going to refine the code and provide what I changed and test
result.
Thanks guys.
> Performance tuning solution for BundleRepository/ResolverImpl
> -
>
> Key: FELIX-3624
> URL: https://issues.apache.org/jira/browse/FELIX-3624
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
> Environment: Geronimo3 + BundleRepository 1.6.6
>Reporter: SheldonShao
>Priority: Critical
> Attachments: Felix_ResolverImpl.png,
> Felix_ResolverImpl_AfterTuning.png, ResolverImpl.java
>
>
> There are too many numebers of method calling about checking whether
> capabities are matched with requiment in ResolverImpl.searchResources.
> This is a performance issue of ResolverImpl.resolve.
> If it creates a capabity to resource+capabity mapping first. Then leverage
> this cache to do requirment matching. It will get better performance.
> Here is part of code. More details please check attachments.
> private final Map m_capabilitiesCache = new HashMap(8192);
> private String getKey(String filter, String prefix) {
> if (filter != null) {
> int index = filter.indexOf(prefix);
> if (index > 0) {
> int end = filter.indexOf(SUFFIX, index +
> prefix.length());
> if (end > index) {
> return filter.substring(index, end);
> }
> }
> }
> return null;
> }
> private String getKey(Requirement requirement) {
> String key = null;
> String name = requirement.getName();
> String filter = requirement.getFilter();
> if (Capability.BUNDLE.equals(name)) {
> key = getKey(filter, PREFIX_SYMBOLICNAME);
> } else if (Capability.PACKAGE.equals(name)) {
> key = getKey(filter, PREFIX_PACKAGE);
> } else if (Capability.SERVICE.equals(name)) {
> key = getKey(filter, PREFIX_SERVICE);
> } else if (Capability.FRAGMENT.equals(name)) {
> key = getKey(filter, PREFIX_HOST);
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> return key;
> }
> private static final String PREFIX_SYMBOLICNAME = "symbolicname=";
> private static final String PREFIX_PACKAGE = "package=";
> private static final String PREFIX_SERVICE = "service=";
> private static final String PREFIX_HOST = "host=";
> private static final String PREFIX_CAPABILITY = "capability=";
> private static final char SUFFIX = ')';
> private void initCache(Capability[] capabilities, Resource resource) {
> Capability cap;
> Map properties;
> String name;
> for (int j = 0; j < capabilities.length; j++) {
> cap = capabilities[j];
> String key = null;
> properties = cap.getPropertiesAsMap();
> name = cap.getName();
> if (Capability.BUNDLE.equals(name)) {
> key = PREFIX_SYMBOLICNAME +
> properties.get("symbolicname");
> } else if (Capability.PACKAGE.equals(name)) {
> key = PREFIX_PACKAGE +
> properties.get("package");
> } else if (Capability.SERVICE.equals(name)) {
> key = PREFIX_SERVICE +
> properties.get("service");
> } else if (Capability.FRAGMENT.equals(name)) {
> key = PREFIX_HOST + properties.get("host");
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> List caps = (List) m_capabilitiesCache.get(key);
> if (caps == null) {
> caps = new ArrayList(2);
> m_capabilitiesCache.put(key, caps);
> }
> caps.add(new ResourceCapabilityImpl(resource, cap));
> }
> }
> private void initCache(Resource[] locals) {
> Resource resource;
> for (int i = 0; i < locals.length; i++) {
> resource = local
Re: [VOTE] Accept the (slightly modified) UserAdmin donation by Jan Willem Janssen
+1 ...and thanks for explaining what happened, Jan Willem!
[jira] [Commented] (FELIX-3624) Performance tuning solution for BundleRepository/ResolverImpl
[
https://issues.apache.org/jira/browse/FELIX-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431755#comment-13431755
]
Marcel Offermans commented on FELIX-3624:
-
Also, it would be nice to include some kind of test that performs the
measurements that you have been using to write this solution. That way we can
easily evaluate what the original problem was and how much better it has become.
> Performance tuning solution for BundleRepository/ResolverImpl
> -
>
> Key: FELIX-3624
> URL: https://issues.apache.org/jira/browse/FELIX-3624
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
> Environment: Geronimo3 + BundleRepository 1.6.6
>Reporter: SheldonShao
>Priority: Critical
> Attachments: Felix_ResolverImpl.png,
> Felix_ResolverImpl_AfterTuning.png, ResolverImpl.java
>
>
> There are too many numebers of method calling about checking whether
> capabities are matched with requiment in ResolverImpl.searchResources.
> This is a performance issue of ResolverImpl.resolve.
> If it creates a capabity to resource+capabity mapping first. Then leverage
> this cache to do requirment matching. It will get better performance.
> Here is part of code. More details please check attachments.
> private final Map m_capabilitiesCache = new HashMap(8192);
> private String getKey(String filter, String prefix) {
> if (filter != null) {
> int index = filter.indexOf(prefix);
> if (index > 0) {
> int end = filter.indexOf(SUFFIX, index +
> prefix.length());
> if (end > index) {
> return filter.substring(index, end);
> }
> }
> }
> return null;
> }
> private String getKey(Requirement requirement) {
> String key = null;
> String name = requirement.getName();
> String filter = requirement.getFilter();
> if (Capability.BUNDLE.equals(name)) {
> key = getKey(filter, PREFIX_SYMBOLICNAME);
> } else if (Capability.PACKAGE.equals(name)) {
> key = getKey(filter, PREFIX_PACKAGE);
> } else if (Capability.SERVICE.equals(name)) {
> key = getKey(filter, PREFIX_SERVICE);
> } else if (Capability.FRAGMENT.equals(name)) {
> key = getKey(filter, PREFIX_HOST);
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> return key;
> }
> private static final String PREFIX_SYMBOLICNAME = "symbolicname=";
> private static final String PREFIX_PACKAGE = "package=";
> private static final String PREFIX_SERVICE = "service=";
> private static final String PREFIX_HOST = "host=";
> private static final String PREFIX_CAPABILITY = "capability=";
> private static final char SUFFIX = ')';
> private void initCache(Capability[] capabilities, Resource resource) {
> Capability cap;
> Map properties;
> String name;
> for (int j = 0; j < capabilities.length; j++) {
> cap = capabilities[j];
> String key = null;
> properties = cap.getPropertiesAsMap();
> name = cap.getName();
> if (Capability.BUNDLE.equals(name)) {
> key = PREFIX_SYMBOLICNAME +
> properties.get("symbolicname");
> } else if (Capability.PACKAGE.equals(name)) {
> key = PREFIX_PACKAGE +
> properties.get("package");
> } else if (Capability.SERVICE.equals(name)) {
> key = PREFIX_SERVICE +
> properties.get("service");
> } else if (Capability.FRAGMENT.equals(name)) {
> key = PREFIX_HOST + properties.get("host");
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> List caps = (List) m_capabilitiesCache.get(key);
> if (caps == null) {
> caps = new ArrayList(2);
> m_capabilitiesCache.put(key, caps);
> }
> caps.add(new ResourceCapabilityImpl(resource, cap));
> }
> }
> private void initCache(Resource[] locals) {
> Resource resource;
> for (int i = 0; i < locals.l
Re: [VOTE] Accept the (slightly modified) UserAdmin donation by Jan Willem Janssen
On 9 Aug 2012, at 07:50, Marcel Offermans wrote: > Since Jan Willem updated the issue [1] after we held the vote, we technically > did not vote on the contribution that will end up in subversion, as Richard > pointed out in that issue. Therefore, although probably a formality, we do > need to revote on this new version so it aligns with the data we provide in > the IP clearance process. So could you all please vote again after looking at > those changes: > > [ ] +1 Accept this donation. > [ ] 0 Don't care. > [ ] -1 Don't accept this donation (please motivate your vote). +1 > Greetings, Marcel > > [1] https://issues.apache.org/jira/browse/FELIX-3600
[jira] [Commented] (FELIX-3624) Performance tuning solution for BundleRepository/ResolverImpl
[
https://issues.apache.org/jira/browse/FELIX-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431657#comment-13431657
]
Felix Meschberger commented on FELIX-3624:
--
First, thanks for reporting and analyzing. I will not comment on the results or
your changes because I don't know that part of the code too deeply.
But you contribution as it stands can unfortunately not be accepted: For one
you forgot to check "Grant license to ASF for inclusion in ASF works" when
uploading your ResolverImpl.java file and second, I (personally) would prefer
to get a diff against current trunk instead of a full file, where it is not
easily visible what the changes actually are.
May I ask you to provide a proper patch and check the grant button ? Thanks.
> Performance tuning solution for BundleRepository/ResolverImpl
> -
>
> Key: FELIX-3624
> URL: https://issues.apache.org/jira/browse/FELIX-3624
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
> Environment: Geronimo3 + BundleRepository 1.6.6
>Reporter: SheldonShao
>Priority: Critical
> Attachments: Felix_ResolverImpl.png,
> Felix_ResolverImpl_AfterTuning.png, ResolverImpl.java
>
>
> There are too many numebers of method calling about checking whether
> capabities are matched with requiment in ResolverImpl.searchResources.
> This is a performance issue of ResolverImpl.resolve.
> If it creates a capabity to resource+capabity mapping first. Then leverage
> this cache to do requirment matching. It will get better performance.
> Here is part of code. More details please check attachments.
> private final Map m_capabilitiesCache = new HashMap(8192);
> private String getKey(String filter, String prefix) {
> if (filter != null) {
> int index = filter.indexOf(prefix);
> if (index > 0) {
> int end = filter.indexOf(SUFFIX, index +
> prefix.length());
> if (end > index) {
> return filter.substring(index, end);
> }
> }
> }
> return null;
> }
> private String getKey(Requirement requirement) {
> String key = null;
> String name = requirement.getName();
> String filter = requirement.getFilter();
> if (Capability.BUNDLE.equals(name)) {
> key = getKey(filter, PREFIX_SYMBOLICNAME);
> } else if (Capability.PACKAGE.equals(name)) {
> key = getKey(filter, PREFIX_PACKAGE);
> } else if (Capability.SERVICE.equals(name)) {
> key = getKey(filter, PREFIX_SERVICE);
> } else if (Capability.FRAGMENT.equals(name)) {
> key = getKey(filter, PREFIX_HOST);
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> return key;
> }
> private static final String PREFIX_SYMBOLICNAME = "symbolicname=";
> private static final String PREFIX_PACKAGE = "package=";
> private static final String PREFIX_SERVICE = "service=";
> private static final String PREFIX_HOST = "host=";
> private static final String PREFIX_CAPABILITY = "capability=";
> private static final char SUFFIX = ')';
> private void initCache(Capability[] capabilities, Resource resource) {
> Capability cap;
> Map properties;
> String name;
> for (int j = 0; j < capabilities.length; j++) {
> cap = capabilities[j];
> String key = null;
> properties = cap.getPropertiesAsMap();
> name = cap.getName();
> if (Capability.BUNDLE.equals(name)) {
> key = PREFIX_SYMBOLICNAME +
> properties.get("symbolicname");
> } else if (Capability.PACKAGE.equals(name)) {
> key = PREFIX_PACKAGE +
> properties.get("package");
> } else if (Capability.SERVICE.equals(name)) {
> key = PREFIX_SERVICE +
> properties.get("service");
> } else if (Capability.FRAGMENT.equals(name)) {
> key = PREFIX_HOST + properties.get("host");
> } else {
> key = PREFIX_CAPABILITY + name;
> }
> List caps = (List) m_capabilitiesCache.get(key);
> if (caps == null) {
>
Re: [VOTE] Accept the (slightly modified) UserAdmin donation by Jan Willem Janssen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/9/12 8:50 AM, Marcel Offermans wrote: > Since Jan Willem updated the issue [1] after we held the vote, we > technically did not vote on the contribution that will end up in > subversion, as Richard pointed out in that issue. Therefore, > although probably a formality, we do need to revote on this new > version so it aligns with the data we provide in the IP clearance > process. So could you all please vote again after looking at those > changes: Just to clarify a bit what's happened here: Yesterday I uploaded new attachments to FELIX-3600 just to fix a typo in the manifest header of one of the contributed bundles (eager to get things right), blatantly ignoring the fact that that was the material voted on and thereby invalidating the earlier vote :( I learned a (hard) lesson... - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is:/ Luminis Technologies B.V. IJsselburcht 3 6825 BS Arnhem +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQI2WbAAoJEKF/mP2eHDc4fFsP/AvAVuwyqOF+UhJFNoDC2NHf IUVsj4iUW3jnMU/JXGEjTnmTa8or6ow4JU7gi6beoxSmEjT1sE0nwhO4whowmt43 zN6gYXmd1jIna7OmVJIVcHweHSBZNBoJwcEKnjuJiaJfQ6IG7PcvPUNtcykv07OA JoCqITCD+sApGfhgkEjfGEwC9zxSFe7CzfK75wU9krP4WPLcYWE2t82gqs17mT8B gqTt6CIjbWWcL4lf/XlpIb9D5QzWwq7kDtA9qJogsGYwCe/jU/L9DFA+/zfIv6fn ISOOcsThDk++LcIlmY5k1tCNxCM5FiMvedLX0On1EAp9NHLyruD9iaVjktVUgrjy jP3RBp/iVX7bLQVE3tvtwo8s12CNUVVu9FQHaUAq4bho+D2LXrqMw+9PTzlhJnT5 Q6f7dvS5BYF0Spuwu27AIoM3/8g4NWVnebz3DLXBRpxkKQcDOV//LhlZc8Dxsk3J p8iKP0jB9HTOt3wswzJwiiJG2imeVk8Rp7ZCFfslh+FXHLgcsUmcNS8eE+m1XP2c m5wHQiVJyKDFty8qDnC9mWU0gzWoEbmGzMnEl4qa1/5AnNtUasjZ2z6J+AF7UjUJ JD32vZL02zT+h7IlCOlZ7K6LVN0yoc1/NRDK2oDyeTME7FpSzKAdiq3d2NU+Mo5O ZVSh3pMCcExaZTOLBYaK =L9TD -END PGP SIGNATURE-
