Task #10359 (accepted)
Opened 12 years ago
Last modified 9 years ago
Bug: getManagedRepo in repository.py is too slow
Reported by: | jamoore | Owned by: | jamoore |
---|---|---|---|
Priority: | critical | Milestone: | Unscheduled |
Component: | API | Version: | n.a. |
Keywords: | fs | Cc: | fs@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
The call to SharedResources.repositories() is taking far too long. This is caused (at least in the integration tests) the server waiting for no longer available repositories to respond. The server should maintain a list of the known active repositories and return these instantly.
Change History (8)
comment:1 Changed 11 years ago by jmoore
- Sprint set to FS Demo 3
comment:2 Changed 11 years ago by mtbcarroll
- Owner changed from jmoore to mtbcarroll
- Status changed from new to accepted
comment:3 Changed 11 years ago by jmoore
comment:4 Changed 11 years ago by mtbcarroll
Ah, I guess that the ticket priority choice may be quite independent of the sprint. I'll go ahead and look at this more as a back-burner thing then.
comment:5 Changed 11 years ago by mtbcarroll
- Owner changed from mtbcarroll to jamoore
- Sprint changed from FS Demo 3 to FS Demo 4
It'd be good to get an integration test working well enough to reliably reproduce this problem; then we can look again at pinning it down and testing a fix.
comment:6 Changed 11 years ago by jburel
- Sprint changed from FS demo 4.x to FS Demo 4.3
Moving to 4.3
comment:7 Changed 11 years ago by jamoore
- Sprint changed from FS Demo 4.3 to FS demo 4.x
This requires API changes that are not really possible pre-Paris. Moving back out of 4.3
comment:8 Changed 9 years ago by jamoore
- Milestone changed from 5.x to Unscheduled
- Sprint FS demo 4.x deleted
Mark, happy to have you look at this, but it's certainly not overly critical for demo 3. The issue primarily arises during development when there are several ManagedRepository entries in the database and only one of them is active. Then the server waits the full 10 seconds to find them.
As the description states, maintaining an up-to-the-minute (-hour?) list of these would probably work well. This could benefit from work on #7902 (MQ).