NullPointerException from Script Runner in JIRA 6.0

Jon Moser June 7, 2013

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

0 votes
Answer accepted
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 1, 2013

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

Jon Moser July 1, 2013

Sounds good. Thanks!

Tom Jackson
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 10, 2013

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.

&(*&)#)_*#@@(*)(@*)(*@
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 3, 2013

2.1.9 is affected

2.1.15 is solving this issue

Jon Moser October 25, 2013

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.

Benu Gupta May 11, 2014

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!

Defence Housing Australia May 11, 2014

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!

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

> 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.


Chris Solgat
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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?

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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.

Chris Solgat
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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?

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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?

Chris Solgat
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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.

Chris Solgat
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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.

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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

Chris Solgat
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2014

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?

1 vote
Yilin
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 9, 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.

Jon Moser June 25, 2013

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
TAGS
AUG Leaders

Atlassian Community Events