NullPointerException from Script Runner in JIRA 6.0

Hello,

We are running in to NullPointerException errors when starting up JIRA 6.0 that appear to be tied in to Script Runner. They don't stop JIRA from starting however we would like to figure out what might be causing them as we are testing for a future upgrade of our production system. Here is one example:

Exception in thread "Thread-31" com.atlassian.util.concurrent.LazyReference$InitializationException: java.lang.NullPointerException
        at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:149)
        at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:112)
        at com.atlassian.util.concurrent.ResettableLazyReference.get(ResettableLazyReference.java:87)
        at com.atlassian.jira.issue.fields.CustomFieldImpl.getCustomFieldSearcher(CustomFieldImpl.java:1805)
        at com.atlassian.jira.issue.fields.CustomFieldImpl.<init>(CustomFieldImpl.java:247)
        at com.atlassian.jira.issue.fields.CustomFieldImpl.<init>(CustomFieldImpl.java:222)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager$CustomFieldCache.cloneCustomFields(DefaultCustomFieldManager.java:730)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager$CustomFieldCache.getAllCustomFields(DefaultCustomFieldManager.java:717)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager$CopyOnWriteCustomFieldCache.getAllCustomFields(DefaultCustomFieldManager.java:621)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getAllCustomFields(DefaultCustomFieldManager.java:417)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldObjects(DefaultCustomFieldManager.java:412)
        at com.atlassian.jira.issue.CustomFieldManager$getCustomFieldObjects.call(Unknown Source)
        at com.onresolve.jira.groovy.ScriptManagerImpl.createIndexingCustomField(ScriptManagerImpl.groovy:466)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1054)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:78)
        at com.onresolve.jira.groovy.ScriptManagerImpl.this$dist$invoke$1(ScriptManagerImpl.groovy)
        at com.onresolve.jira.groovy.ScriptManagerImpl$1.methodMissing(ScriptManagerImpl.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:811)
        at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1103)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1056)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:884)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:137)
        at com.onresolve.jira.groovy.ScriptManagerImpl$1.run(ScriptManagerImpl.groovy:392)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
        at com.atlassian.jira.util.JiraUtils.loadComponent(JiraUtils.java:96)
        at com.atlassian.jira.util.JiraUtils.loadComponent(JiraUtils.java:91)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.loadSearcher(DefaultCustomFieldManager.java:286)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldSearcher(DefaultCustomFieldManager.java:273)
        at com.atlassian.jira.issue.fields.CustomFieldImpl$CustomFieldSearcherLazyRef.create(CustomFieldImpl.java:2099)
        at com.atlassian.jira.issue.fields.CustomFieldImpl$CustomFieldSearcherLazyRef.create(CustomFieldImpl.java:2079)
        at com.atlassian.util.concurrent.ResettableLazyReference$InternalReference.create(ResettableLazyReference.java:140)
        at com.atlassian.util.concurrent.LazyReference$Sync.run(LazyReference.java:321)
        at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:143)
        at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:112)
       at com.atlassian.util.concurrent.ResettableLazyReference.get(ResettableLazyReference.java:87)
        at com.atlassian.jira.issue.fields.CustomFieldImpl.getCustomFieldSearcher(CustomFieldImpl.java:1805)
        at com.atlassian.jira.issue.fields.CustomFieldImpl.<init>(CustomFieldImpl.java:247)
        at com.atlassian.jira.issue.fields.CustomFieldImpl.<init>(CustomFieldImpl.java:222)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager$CustomFieldCache.cloneCustomFields(DefaultCustomFieldManager.java:730)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager$CustomFieldCache.getAllCustomFields(DefaultCustomFieldManager.java:717)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager$CopyOnWriteCustomFieldCache.getAllCustomFields(DefaultCustomFieldManager.java:621)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getAllCustomFields(DefaultCustomFieldManager.java:417)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldObjects(DefaultCustomFieldManager.java:412)
        at com.atlassian.jira.issue.CustomFieldManager$getCustomFieldObjects.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
        at com.onresolve.jira.groovy.ScriptManagerImpl.createIndexingCustomField(ScriptManagerImpl.groovy:466)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1054)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:78)
        at com.onresolve.jira.groovy.ScriptManagerImpl.this$dist$invoke$1(ScriptManagerImpl.groovy)
        at com.onresolve.jira.groovy.ScriptManagerImpl$1.methodMissing(ScriptManagerImpl.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:811)
        at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1103)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1056)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:884)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
        ... 3 more

Has any one seen this with JIRA 6.0 and Script Runner 2.1.3?

Thanks!

2 answers

1 accepted

This widget could not be displayed.

Hi - I'm aware of this and investigating... should be fixed in next release. There is a bug for it.

Sounds good. Thanks!

We just ran into this bug. We tried to upgrade a 5.2.11 instance to 6.0.8 that had Script runner 2.1.7 installed. I rolled back, uninstalled script runner, and was able to successfully upgrade.

2.1.9 is affected

2.1.15 is solving this issue

Did you have to do anything with 2.1.15 to get it to solve this? We are testing moving from JIRA 6.0 to JIRA 6.1.1 and are running in to this issue again.

We are experiencing similar issues with Jira 5.2.11 and Script Runner 2.1.15. Once in a while, the error below is also seen in the server logs besides the NPE at start-up and a restart is required to fix it.

Caused by: com.atlassian.util.concurrent.LazyReference$InitializationException: java.util.ConcurrentModificationException
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:152)
at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:115)
.

.
.

at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:146)
at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:115)
at com.atlassian.util.concurrent.ResettableLazyReference.get(ResettableLazyReference.java:89)
at com.atlassian.util.concurrent.Supplier$get.call(Unknown Source)
at com.onresolve.jira.groovy.ScriptManagerImpl.registerScriptedJqlFunctions(ScriptManagerImpl.groovy:119)

.

.

Any updates on when the fix will be available?

Thanks for your help!

We are experiencing similar issues with Jira 5.2.11 and Script Runner 2.1.15. Once in a while, the error below is also seen in the server logs besides the NPE at start-up and a restart is required to fix it.

Caused by: com.atlassian.util.concurrent.LazyReference$InitializationException: java.util.ConcurrentModificationException
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:152)
at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:115)
.

.
.

at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:146)
at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:115)
at com.atlassian.util.concurrent.ResettableLazyReference.get(ResettableLazyReference.java:89)
at com.atlassian.util.concurrent.Supplier$get.call(Unknown Source)
at com.onresolve.jira.groovy.ScriptManagerImpl.registerScriptedJqlFunctions(ScriptManagerImpl.groovy:119)

.

.

Any updates on when the fix will be available?

Thanks for your help!

> With that being said, my feeling is that when a module gets disabled, it acts as a type of "refresh

Yeah that's true... it listeners to any plugin module getting disabled/enabled, so it can reregister its jql functions.


We have been experiencing this as well. We upgraded to Jira 6.1.6 and Scriptrunner 2.1.16. In researching I found GRV-338. There was a comment at the bottom of the page that said he simply disabled one of the Script Runner Modules and then re-enabled it and that cleared up the error. I have been testing this in some dev evironments and have been able to replicate. With this possibility, I went back to the logs and noticed that my first error always shows up during the plugin initialization. Because we have tested many different ways to resolve this error, we have noticed that it doesn't seem to be script runner alone, but the combination of another plugin (which we haven't determined). Anyways, on plugin initialization, it appears that the Script Runner plugin is not able find something correctly and throws the error. We have tried disabling and enabling at least three different modules, all with the same results: the error clears up. With that being said, my feeling is that when a module gets disabled, it acts as a type of "refresh" for the plugin and is now able to find whatever it couldn't before. I would like to try and rearrange the order in which the plugins are initialized to further test/prove this theory. Any thoughts?

I recommend you upgrade to the latest 3.0-beta... which is compatible with jira 6.2. If you can.

Much of this has changed, and no work is going to be done backporting fixes.

At the moment, the consideration for upgrading is on the back burner. As a company we currently have 5 Production environments and 11 development environments. Also, we are planning an additional 3 environments next month. Doing an upgrade is quite a serious process for us and cannot just be done on a whim. Is there any way to put a 3 - 5 second delay on initializing the script runner plugin, or have you ever heard of reordering the way plugins are initialized?

Trust me, I am fully aware of the issues in managing multiple production environments. Hence the need to repackage jira into an rpm containing all the plugins you use and any other configuration, to make the process as smooth as possible.

> plugin, or have you ever heard of reordering the way plugins are initialized?

Can you try to find the other plugin it's interacting with?

I only ask, because of our automated restarts. It is of course not preferable to have to babysit each restart and make the changes manually every time.

I have started down that path but because it seems that a possible workaround has been put into place, the chances of being able to fully test that out are small. Also, this error does not happen in every environment, only certain ones, which I believe adds credence to it simply being a timing issue on initialization. Since we haven't had any other plugins throwing the error, there's not really a place to start. This means disabling each plugin one at a time and if it ends up being a system plugin, I would be looking at days to maybe weeks, and I'm sure I won't be allotted that amount of time. For now, I just need to see if I can find a way to delay the initialization of Script runner long enough for the other plugins to load.

I can't think of anything, except maybe in your startup script you use curl to disable/enable it. But that's pretty nasty.

Sorry, I know this doesn't really go here, but I created a profile for your on demand instance (to create an issue for script runner) but I can't add an issue. Is this correct? Also, is there a better way to try and contact you, since commenting has been disabled on your wiki?

This widget could not be displayed.
Yilin Mo Atlassian Team Jun 09, 2013

Regarding to the error message, it seems that script runner found one customfield with NULL searcher, Maybe you can check that with the following query:

select * from customfield where customfieldsearcherkey is NULL;

Or maybe you can contact the plugin provider for more info.

Sorry for the delay in replying to this. We weren't able to figure out what field was causing this but determined it didn't seem to be causing any issues so are holding off troubleshooting for now. Thanks for your help!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Aug 22, 2018 in Marketplace Apps

How a Marketplace app tech team is achieving gender diversity

Hello! My name is Genevieve Blanch, and I'm the Marketing Manager at RefinedWiki, creators of apps to give teams the tools to customize Atlassian platforms. Currently, 44% of the tech team at Re...

428 views 3 17
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you