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?
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.
If you're seeing the same underlying problem that I am, related issues seem to be:
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 ;)
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot