Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

very slow for big JIRA instance #3

Closed
GoogleCodeExporter opened this issue Mar 9, 2016 · 6 comments
Closed

very slow for big JIRA instance #3

GoogleCodeExporter opened this issue Mar 9, 2016 · 6 comments

Comments

@GoogleCodeExporter
Copy link

Problem
- It looks like the code will try to fetch the list of all users which can be 
really huge list especially in a corporate environment (sometimes 2000+)
- It also tries to fetch all issues by using getIssuesFromTextSearch("") by 
default which can be really slow as well.

Action
- It should find out which projects the current user has right to browse via 
getProjectsNoSchemes
- It then probably should find out who are allowed to access those projects
- It should then have some sort of caching to cache users/project list so 
that it won't try to retrieve it over and over again.

Original issue reported on code.google.com by nat.lu...@gmail.com on 24 Oct 2009 at 12:04

@GoogleCodeExporter
Copy link
Author

>> It also tries to fetch all issues by using getIssuesFromTextSearch("") by 
default which can be really slow as well.

Your correct, this is a 'know issue' with the "[All Issues]" filter on almost 
any 
size of a project.  I should have removed it along time back.  Jira 4.0 doesn't 
allow 
empty searches anymore and as such I will be removing it.  Generally I use 
custom 
filters, in future releases this will be required.

>> It looks like the code will try to fetch the list of all users which can be 
really huge list especially in a corporate environment (sometimes 2000+)

The user names come from the issues you have viewed... I'll look into why this 
is 
causing a performance issue, but I don't make a specific request for users.  
The 
problem may be trying to get a display name or something.  I'll look at it.

Original comment by Grig...@gmail.com on 29 Oct 2009 at 3:14

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Waiting for user to provide more information.

Original comment by Grig...@gmail.com on 21 Nov 2009 at 4:43

  • Changed state: Waiting

@GoogleCodeExporter
Copy link
Author

What would you like to know?

Original comment by nat.lu...@gmail.com on 24 Nov 2009 at 12:03

@GoogleCodeExporter
Copy link
Author

Sorry about that, wrong issue.  Apparently I managed to mishandle one of the 
five 
defects, how sad.

Anyway, I found that I am making a round-trip for each user name encountered in 
order 
to retrieve a display name for the user.  I cache the information so hopefully 
this 
isn't horrible after it's populated; however, I think it worth offering an 
option to 
disable it.  I'll be working on that option as soon as time permits.

On the other side the 'All Issues' is being replaced and may just go away all 
together if I can't find a reasonable solution.

Original comment by Grig...@gmail.com on 24 Nov 2009 at 1:46

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Great. Looking forward to the new release. Let me know if I can help in 
anyway...

Original comment by nat.lu...@gmail.com on 24 Nov 2009 at 3:29

@GoogleCodeExporter
Copy link
Author

Fixed in  1.10.607.213 - I've added an option in the configuration file:

<add key="resolveUserNames" value="true"/>

set this value to "false" to disable fetching full user names on instances with 
a large user count.

Original comment by Grig...@gmail.com on 15 Jun 2010 at 5:38

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant