Unable to create queues

[gilse]

I am currently trying to create a queue for a new Service Desk Project. Unluckily I am unable to save my queues, calatina.out is providing the attached error message. Is this a known problem?

2018-06-06 10:10:20,107 http-nio-1081-exec-10 ERROR <username> 610x154x1 192r6a6 (null),<user-ip>,127.0.0.1 /rest/servicedesk/1/servicedesk/<projectname>/queues [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: com.querydsl.sql.dml.SQLInsertClause.getBatchCount()I

java.lang.NoSuchMethodError: com.querydsl.sql.dml.SQLInsertClause.getBatchCount()I

 at com.atlassian.servicedesk.internal.feature.queue.QueueStore.addColumns(QueueStore.java:218)

 at com.atlassian.servicedesk.internal.feature.queue.QueueStore.addQueue(QueueStore.java:111)

 at com.atlassian.servicedesk.internal.feature.queue.QueueManagerImpl.lambda$null$4(QueueManagerImpl.java:80)

 at io.atlassian.fugue.Either$RightProjection.map(Either.java:872)

 at io.atlassian.fugue.Either.map(Either.java:217)

 at com.atlassian.servicedesk.internal.feature.queue.QueueManagerImpl.lambda$addQueue$5(QueueManagerImpl.java:80)

 at com.atlassian.pocketknife.internal.querydsl.DatabaseAccessorImpl.lambda$execute$0(DatabaseAccessorImpl.java:69)

 at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.executeInternal(DefaultTransactionalExecutor.java:86)

 at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.lambda$execute$0(DefaultTransactionalExecutor.java:42)

 at com.atlassian.jira.database.DatabaseAccessorImpl.runInManagedTransaction(DatabaseAccessorImpl.java:125)

 ... 2 filtered

 at java.lang.reflect.Method.invoke(Method.java:498)

 at com.atlassian.plugin.util.ContextClassLoaderSettingInvocationHandler.invoke(ContextClassLoaderSettingInvocationHandler.java:26)

 at com.sun.proxy.$Proxy170.runInManagedTransaction(Unknown Source)

 ... 2 filtered

 at java.lang.reflect.Method.invoke(Method.java:498)

 at com.atlassian.plugin.osgi.bridge.external.HostComponentFactoryBean$DynamicServiceInvocationHandler.invoke(HostComponentFactoryBean.java:136)

 at com.sun.proxy.$Proxy170.runInManagedTransaction(Unknown Source)

 at com.atlassian.sal.jira.rdbms.JiraHostConnectionAccessor.runInStartedOrExistingTransaction(JiraHostConnectionAccessor.java:130)

 at com.atlassian.sal.jira.rdbms.JiraHostConnectionAccessor.execute(JiraHostConnectionAccessor.java:60)

 at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.execute(DefaultTransactionalExecutor.java:39)

 at com.atlassian.pocketknife.internal.querydsl.DatabaseAccessorImpl.execute(DatabaseAccessorImpl.java:67)

 at com.atlassian.pocketknife.internal.querydsl.DatabaseAccessorImpl.runInTransaction(DatabaseAccessorImpl.java:43)

 at com.atlassian.servicedesk.internal.feature.queue.QueueManagerImpl.addQueue(QueueManagerImpl.java:73)

 at com.atlassian.servicedesk.internal.feature.queue.QueueServiceInternalImpl.addQueue(QueueServiceInternalImpl.java:62)

 at com.atlassian.servicedesk.internal.rest.QueueResourceInternal.addQueue(QueueResourceInternal.java:248)

 at com.atlassian.servicedesk.internal.rest.QueueResourceInternal.lambda$addQueue$1(QueueResourceInternal.java:96)

 at com.atlassian.pocketknife.step.EitherStep2.lambda$null$0(EitherStep2.java:20)

 at io.atlassian.fugue.Either$RightProjection.flatMap(Either.java:886)

 at io.atlassian.fugue.Either.flatMap(Either.java:231)

 at com.atlassian.pocketknife.step.EitherStep2.lambda$then$1(EitherStep2.java:20)

 at io.atlassian.fugue.Either$RightProjection.flatMap(Either.java:886)

 at io.atlassian.fugue.Either.flatMap(Either.java:231)

 at com.atlassian.pocketknife.step.EitherStep2.then(EitherStep2.java:20)

 at com.atlassian.servicedesk.internal.rest.QueueResourceInternal.addQueue(QueueResourceInternal.java:96)

 ... 3 filtered

 at java.lang.reflect.Method.invoke(Method.java:498)

 ... 18 filtered

 at com.atlassian.plugins.rest.module.RestDelegatingServletFilter$JerseyOsgiServletContainer.doFilter(RestDelegatingServletFilter.java:154)

 ... 1 filtered

 at com.atlassian.plugins.rest.module.RestDelegatingServletFilter.doFilter(RestDelegatingServletFilter.java:68)

 ... 32 filtered

 at com.atlassian.servicedesk.internal.web.ExternalCustomerLockoutFilter.doFilter(ExternalCustomerLockoutFilter.java:56)

 ... 4 filtered

 at com.atlassian.servicedesk.internal.web.UrlOperationalStatusCheckFilter.doFilterWhenLicensed(UrlOperationalStatusCheckFilter.java:38)

 at com.atlassian.servicedesk.internal.web.OperationalStatusAwareHttpFilter.doFilter(OperationalStatusAwareHttpFilter.java:27)

 ... 4 filtered

 at com.atlassian.servicedesk.internal.web.PopulateEyeballForRestFilter.doFilterWhenLicensed(PopulateEyeballForRestFilter.java:36)

 at com.atlassian.servicedesk.internal.web.OperationalStatusAwareHttpFilter.doFilter(OperationalStatusAwareHttpFilter.java:27)

 ... 13 filtered

 at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21)

 ... 53 filtered

 at com.atlassian.jira.security.JiraSecurityFilter.lambda$doFilter$0(JiraSecurityFilter.java:66)

 ... 1 filtered

 at com.atlassian.jira.security.JiraSecurityFilter.doFilter(JiraSecurityFilter.java:64)

 ... 16 filtered

 at com.atlassian.plugins.rest.module.servlet.RestSeraphFilter.doFilter(RestSeraphFilter.java:37)

 ... 19 filtered

 at com.atlassian.jira.servermetrics.CorrelationIdPopulatorFilter.doFilter(CorrelationIdPopulatorFilter.java:30)

 ... 5 filtered

 at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.lambda$invokeFilterChain$0(CustomerContextSettingFilter.java:181)

 at com.atlassian.servicedesk.internal.api.util.context.ReentrantThreadLocalBasedCodeContext.rteInvoke(ReentrantThreadLocalBasedCodeContext.java:137)

 at com.atlassian.servicedesk.internal.api.util.context.ReentrantThreadLocalBasedCodeContext.runOutOfContext(ReentrantThreadLocalBasedCodeContext.java:90)

 at com.atlassian.servicedesk.internal.utils.context.CustomerContextServiceImpl.runOutOfCustomerContext(CustomerContextServiceImpl.java:47)

 at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.outOfCustomerContext(CustomerContextSettingFilter.java:174)

 at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.doFilterImpl(CustomerContextSettingFilter.java:130)

 at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.doFilter(CustomerContextSettingFilter.java:121)

 ... 4 filtered

 at com.atlassian.jwt.internal.servlet.JwtAuthFilter.doFilter(JwtAuthFilter.java:32)

 ... 8 filtered

 at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21)

 ... 4 filtered

 at com.atlassian.web.servlet.plugin.LocationCleanerFilter.doFilter(LocationCleanerFilter.java:36)

 ... 26 filtered

 at com.atlassian.jira.servermetrics.MetricsCollectorFilter.doFilter(MetricsCollectorFilter.java:25)

 ... 23 filtered

 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

 at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

 at java.lang.Thread.run(Thread.java:745)

  

[Andy Heinzer · Accepted solution]

Did you recent upgrade Service Desk?  Could you please let me know what specific versions of both Jira and Service Desk you are using here?

I found a few other customer reported cases with your specific error message.  In these other cases, it appears that some users find in their Jira an older version of a system plugin called

         querydsl-4.0.7-provider-plugin                : com.atlassian.querydsl.plugins.querydsl-4.0.7-provider-plugin
              Version                                       : 1.1
              Status                                        : enabled
              Vendor                                        : Atlassian
              Description                                   : This plugin provides QueryDSL 4.0.7.

It seems that in at least a few cases, this particular plugin is not getting the necessary update that Service Desk depends on.   We are still trying to determine what steps are necessary to reproduce this so we can create a bug ticket,

In the meantime, I found a set of steps that seems to work to fix this:

Can you please try the following steps and let me know if it resolves the issue?

1. Download the querydsl 4.1.4 plugin jar file in this link: querydsl-4.1.4-provider-plugin-1.0.jar
2. Stop JIRA
3. Remove the querydsl jar file that is located in the directory $JIRA_HOME/plugins/installed-plugins (the file name should be similar to querydsl-4.0.7-provider-plugin-1.1)
4. Copy the downloaded file into this same /installed-plugins/ folder
5. Start JIRA

Please let me know the results and the answers to the questions above.

Thanks,

Andy

[gilse]

Hello Andy,

the new jar-File did the trick.

The querydsl-4.0.7-provider-plugin-1.1.jar was still in place.

After a shutdown -> drop-in replacement -> start of jira, everything is working as inspected. 

I recently upgraded from Jira Software 7.8.0 to Jira Software 7.10 ( June 2nd ) and also upgraded to ServiceDesk 3.13

Thanks for your help.

Cheers,

Guido

[Andy Heinzer]

Thanks @gilse

We're still trying to determine why that plugin is not always getting updated during the upgrades.  I created a bug on this issue today in https://jira.atlassian.com/browse/JSDSERVER-5847

For other users that come across this thread, please watch/vote on this bug ticket to help us understand the how many Service Desk installs are affected by this same problem.

[Azimir Hotic]

I have this exact same issue and i will try the steps you provided tonight after hours and let you know if it worked. 

[Azimir Hotic]

I just tried applying the querydsl 4.1.4 plugin jar file to my replica test environment and after rebooting Jira I do not see the queues any longer in the left column.  I have tried removing the new JAR file and adding back the old one but still, don't see the queues. I am not sure what happened. I restored my test environment to the Snap I took before I did the change. 

Any Ideas?  I don't want to do this in production until i know it works in the test environment.

[Andy Heinzer]

These steps should have fixed this problem on those specific version upgrades.  If they didn't for you, I'd be interested to learn more about what version you are upgrading to for both Jira and Jira Service Desk.   It's possible there are other potential causes for this problem aside from that one plugin.  If other service desk system plugins fail to start up, it could cause this kind of behavior.  But Jira should create a log entries if this happens in the $JIRAHOME/log/atlassian-jira.log file if/when this happens.

It might also help to take a look at what plugins are disabled in Jira.  You can do this with a SQL query on the jira database of

select * from pluginstate;

If there are any dependencies for Service Desk here, such as the Jira working hours plugin, then this can prevent Service Desk from starting when Jira starts.

[Henrik Ridder]

We have the same problem. I will try changing the querydsl.jar file and see if this solves this.

[Henrik Ridder]

After replacing the querydsl file everything worked as intended.

We updated to Jira 7.10.1 and Service Desk 3.13.1 in June.

[Mike McNamara]

We had same issue and replacing querydsl fixed it. We originally installed JIRA 7.9, then upgraded to 7.10.1. After a few months installed trial of Service Desk 3.13.1 no 11/13/2018, and this issue occurred immediately as I worked through the tutorial.