felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Lyaruu (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-5151) Scr Bind methods occasionally gets a null service reference
Date Wed, 23 Dec 2015 12:54:46 GMT
Frank Lyaruu created FELIX-5151:

             Summary: Scr Bind methods occasionally gets a null service reference
                 Key: FELIX-5151
                 URL: https://issues.apache.org/jira/browse/FELIX-5151
             Project: Felix
          Issue Type: Bug
          Components: Declarative Services (SCR)
    Affects Versions: scr-1.8.2
         Environment: Felix 4.4.0, MacOS, Java 8b66
            Reporter: Frank Lyaruu

Hi Felix devs,

I'm having an intermittent issue with null services being passed to SCR bind methods. 

For example in this piece of code:

    @Reference(name = "GitRepository", unbind = "removeGitRepository",policy=ReferencePolicy.DYNAMIC,cardinality=ReferenceCardinality.MULTIPLE,target="(bare=true)")
    public synchronized void addGitRepository(GitRepository bareRepository, Map<String,Object>
settings) {
      if(bareRepository==null) {
        logger.warn("add reference got passed a null. Settings: "+settings);
      // ....

Most of the time it works fine, but from time to time a null reference gets passed.

The output of the above snippet looks like this:

[main] WARN com.dexels.consul.repositoryloader.impl.RepositoryListenerImpl - add reference
got passed a null (thread: main). Settings: {url=https://github.com/foo/bar, component.name=dexels.repository.git.bare,
id=backoffice, token=xxx, service.factoryPid=dexels.repository.git.bare, objectClass=[Ljava.lang.String;@60baef24,
bare=true, repositoryname=foo, service.pid=dexels.repository.git.bare.5fd0cefd-ec30-4418-92d4-a708792590d8,
component.id=44, event.topics=[Ljava.lang.String;@6692b6c6, service.id=95}

And then it fails with an NPE when it tries to use the service:


  at com.dexels.consul.repositoryloader.impl.RepositoryListenerImpl.addGitRepository(RepositoryListenerImpl.java:135)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:497)
  at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
  at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
  at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
  at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
  at org.apache.felix.scr.impl.helper.BindMethod.invoke(BindMethod.java:37)
  at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1608)
  at org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1473)
  at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:277)
  at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:127)

I see this issue pop up from time to time across different services and different applications.
It is pretty rare, but it does cause instability and it is tricky to work around. If I switch
to equinox + equinox declarative services, this issue goes away.

It is quite a pain to reproduce, but I have captured it in a debugger a few times:

What I see there is that the org.apache.felix.scr.impl.helper.BindMethod.getParameters:605

            return new Object[] {refPair.getServiceObject(), new ReadOnlyDictionary( refPair.getRef()

The first array element: refPair.getServiceObject() yields null from time to time.

In RefPair.getServiceObject():

    public T getServiceObject()
        return serviceObjectRef.get();

Where serviceObjectRef is an AtomicReference, and this is as far as my research got.
I realise this is not the best bug report ever, but is there anyone who has seen this before
and can shed some light? 

regards, Frank

This message was sent by Atlassian JIRA

View raw message