We have encountered an issue that crashes JIRA when a user clicks on PROJECT within the Timesheet view. We have traced the issue to the user previously viewing a large period of time (say 3+months) so when they click PROJECT it defaults to that last view period of time and attempts to poll EVERY ticket and EVERY worklog within that timeframe creating the pull on resources. The challenge is that we have JIRA projects that are rather HUGE and some of them have hundreds of tickets entered monthly with numerous worklogs associated.
We are running Tempo version 7.6.3 on JIRA 5.1.8
So my questions are:
Though I couldn't find any similarly worded issues in this forum, I have to think we're not the only ones?
Thank you for your time and assistance!
This was improved in Tempo Timesheets version 7.7.1 (see e.g. https://tempoplugin.jira.com/browse/JTMPO-959)
A workaround until you update is to ask the user in question to visit this url: [YOUR-SERVER]/secure/TempoUserBoard!timesheet.jspa?periodView=WEEK
That should put him in week view.
We recently upgraded to Tempo Version 7.7.2 running JIRA 5.2.11 yet we still are having issues when attempting to view time by PROJECT. It creates a tremendous strain on the server's memory and ulimately will crash JIRA. How do I go about collecting a log so that I can have you guys take a look? I know some of our projects are rather large, but I can't imagine we are the only ones having this issue?
we are always working on performance improvements but viewing long timeperiods in the Timesheet view. If you want to create a report that gives you data for a longer time period, we recommend using the XML export (see also https://tempoplugin.jira.com/wiki/display/TEMPO077/Tempo+Servlet+Manual).
If you want us to take a look at this, please create an issue in our Tempo support project (https://tempoplugin.jira.com/browse/JTS). Please attach the JIRA log file (atlassian-jira.log) so we can better investigate this problem.
Thank you for your reply. Actually it will crash if only pulling a SINGLE day's worth of time by Project. Which would only be between 100-300 worklog entries. Understandable if it were looking at a larger timeframe but I would think a day shouldn't bring the whole system down? What is curious, is I can do the same type of query when searching for issues (Project=XX) which returns 300k+ issues that extend back YEARS and JIRA has no issues pulling these large data sets. I undersand xml is an option however it certainly isn't a viable options for our end users.
I will post a log and hopefully there is some configuration or something that I am missing or an alternative fix. Also wondering why Benedikt mentioned above that this issue was resolved in 7.7.2 ? This is something I relayed to our executive team (who authorized the initial purchase and implementation of Tempo) so if I go back to them with a "it's still broken" message after upgrading, well, let's just say I'm not looking forward to that.
You are perfectly right, the product should just work and you should not need to use XML. The reason that JIRA can return 300k issues is that they store issues in a Lucene index but have not done the same for worklogs. We have done a lot of performance improvements since 7.7. JIRA has also made some imrovements in the JIRA 6.x series.
If you are on the latest relese and are still encountering problems, then please let us know and our team will fix it. It is best to send request to our support directly (email@example.com) or create a JIRA issue at https://tempoplugin.jira.com/browse/JTS
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs