Richard,
Can you share your hack with me? I have the same problem.
Joel
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you're seeing the same underlying problem that I am, related issues seem to be:
https://answers.atlassian.com/questions/72219/jira-5-0-email-delays
https://answers.atlassian.com/questions/96857/jira-notification-mail-queue-is-hung-in-5-1-3
https://answers.atlassian.com/questions/125255/jira-email-delays
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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...)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Tough luck then. You might have to recompile the JiraSchedulerFactory class to do this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Modify the quartz.properties in WEB-INF/classes. The quartz that JIRA is using shuold be 1.5.1
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.