NJLangley / csharptest-net

Automatically exported from code.google.com/p/csharptest-net
0 stars 0 forks source link

very slow for big JIRA instance #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
>> 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

GoogleCodeExporter commented 8 years ago
Waiting for user to provide more information.

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

GoogleCodeExporter commented 8 years ago
What would you like to know?

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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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