Is there a way to modify the threadCount of the quartz Scheduler in JIRA?

Carlo Bottiglieri August 14, 2013

Thread Pool default for JIRA is set to 2 threads. Is there a way to raise this limit?

7 answers

0 votes
Rich Fromm September 16, 2013
Sorry for the delay in responding, I don't check this regularly. I'll have to explore the best way of uploading this -- it's spread across a series of files. And double check with my employer that it's okay.
0 votes
Joel Harvey September 10, 2013

Richard,


Can you share your hack with me? I have the same problem.

Joel

0 votes
Carlo Bottiglieri September 1, 2013

Just to give a bit more feedback. We've a JIRA instance running on 5.0.6. Lots of services jobs are running on this instance (Administration -> services) like SVN indexes, mail queue, etc... Some weeks ago we had to change the LDAP query filter and this consumed a lots of ressources (We have a hudge AD). After that action I realised that sometime after the startup of JIRA instance, the scheduler just stop to trigger "ServicesTrigger"... It keeped the date in the past, so no more trigger happened. I looked around to find the reason of that issue without any succes... Then I thought that it was maybe due to the number of thread available for jobs... which is "2"... and try to raise this limit to see if the problem solves.... But after a few investigation I also try to raise the JVM memory (was set to 2GB), I raised it to 3Gb (On a 64bit system). Now the issue seems solved by raising the JVM memory (But I have no explanation on this point... maybe a thread was waiting on GC or something else). Anyway the question is still a good question. Or could it be a good reason to raise the scheduler thread limit? If so how?

Thanks for you all your feedback until now. Very interesting to share opinions and knowledge with you ;)

Cheers.

0 votes
Rich Fromm August 22, 2013

Can you give a little more information about why you think this is the thing to set, and what exactly you mean by the "manually flush mail queue" issue?

What I'm seeing is that both incoming and outgoing mail build up in the queue. On the order of 100s of messages. Every once in a while, if left on its own, the queue will empty. Typically this happens roughly every 30 minutes, but it's variable; and this is despite the fact that it's supposed to happen every 1 minute. There is nothing in the logs (even with debug logging enabled for incoming and outgoing mail) to indicate that anything is going wrong.

However, if I flush the mail queue with the button on the web page from the admin console, it works, and fairly rapidly. In seconds, well under a minute.

So I wrote a horribly hacky script to automate pushing the button once a minute. Now I never have anything in the queue that's more than a minute old. But I'd like a less hacky solution.

Does this mirror the kind of behavior that you're seeing? Do you have any evidence that the problem is a lack of threads in the quartz scheduler? I haven't been able to find any useful debugging information in the logs about any scheduling problems.

My theory is that the perhaps the scheduler is overloaded, and then this happens, it just silently drops items from the queue. And that the only reason it works every once in a while is just luck, and not some inherent behavior related to how much time has passed or how many messages have built up.

Rich Fromm August 23, 2013

Fwiw, I tried the quartz.properties suggestion above, and got exactly the same result. This is with JIRA 5.2 and quartz 1.5.1.

At this point I am likely to stick with my horrible hack.

0 votes
Carlo Bottiglieri August 18, 2013

Hum there must be a way to do that through a xml file (from tomcat) or something like that... I'm still looking for a solution because we have to many jobs runnings and now some of them are just skipped (and we fall in the "manually flush mail queue" issue...)

0 votes
Carlo Bottiglieri August 15, 2013

I already tried it:

in WEB-INF/classes -> org.quartz.threadPool.threadCount=5

And I get the following error:

2013-08-16 14:29:50,637 main ERROR [com.atlassian.jira.ContainerRegistrar] Exception registering component instance for Scheduler Factory

org.quartz.SchedulerException: ThreadPool class 'com.atlassian.multitenant.quartz.MultiTenantThreadPool' props could not be configured. [See nested exception: java.lang.NoSuchMethodException: No setter for property 'threadCount']

So what should is set in quartz.properties to make it work?

Timothy
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.
August 15, 2013

Tough luck then. You might have to recompile the JiraSchedulerFactory class to do this.

0 votes
Timothy
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.
August 15, 2013

Modify the quartz.properties in WEB-INF/classes. The quartz that JIRA is using shuold be 1.5.1

Suggest an answer

Log in or Sign up to answer