Defect #1931
openTimeout risks: need asynchronous operations
0%
Description
As notified by Calvin in the forums(http://www.redmine.org/boards/2/topics/2327), big SCM repositories cause web servers to timeout access to repository views. It's not a good idea to encourage people to set long timeout their web server. A solution is to wrap potential long call in asynchronous process:
- Find out every potential long call
- Wrap it in an asynchronous process
- Add a "waiting hook" on that page, with a js observer to check when the call take end
For my part, I think it's an important defect (so the priority) and not a little yard, but a doable one.
I'm open to every suggestion about a different way to fix it.
Related issues
Updated by Eric Davis over 16 years ago
+1 I ended up turning off my SCM's autofetch commits and have a cronjob as a workaround. Problem is, the cronjob only runs every hour so my Redmine is always behind.
Updated by Nicolas Chuche over 16 years ago
Eric Davis wrote:
+1 I ended up turning off my SCM's autofetch commits and have a cronjob as a workaround. Problem is, the cronjob only runs every hour so my Redmine is always behind.
Using cron is the recommended way to do. I've worked on local cache for subversion and git (in branches/nbc for the moment) to speed things up but even than, creating a svnmirror of a repository can take a loooooong time.
We've talked about using something like backgroundrb instead of cron but it's not a priority for the moment. I would like to do other things before that.
I'm very bad in js so if someone can drop me a patch implementing the observer part Thomas speak about, I could try to implement the rails part.
Updated by Eric Davis over 16 years ago
Nicolas Chuche wrote:
I'm very bad in js so if someone can drop me a patch implementing the observer part Thomas speak about, I could try to implement the rails part.
Don't think the observer would be that difficult. You can use periodically_call_remote
from Rails with it pointed to an action that checks the status of the process. The action would return a busy if the process is still working or the response if it's complete (e.g. the updated svn browser)
We've talked about using something like backgroundrb instead of cron but it's not a priority for the moment. I would like to do other things before that.
I'd agree with you there. Ideally I would like to get some other improvements in Redmine before we optimize things.
Updated by Gabriel Mazetto almost 12 years ago
This sounds like Delayedjobs or better Sidekiq could be optionally used here... This is a good time to start thinking about it, because Rails 4 will arrive with a Queue API, so more and more applications will start using async jobs.
Updated by Toshi MARUYAMA over 9 years ago
- Related to Defect #2824: MySQL Deadlock Error when showing a big repository added