Defect #1931

Timeout risks: need asynchronous operations

Added by Thomas Lecavelier almost 11 years ago. Updated over 3 years ago.

Status:NewStart date:2008-09-22
Priority:HighDue date:
Assignee:-% Done:

0%

Category:SCMEstimated time:8.00 hours
Target version:-
Resolution: Affected version:

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:

  1. Find out every potential long call
  2. Wrap it in an asynchronous process
  3. 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

Related to Redmine - Defect #1435: slow display of 'repository' tab for huge repository (pag... Closed 2008-06-12
Related to Redmine - Defect #7002: mysql timeout when first browsing a large git repository Closed 2010-11-30
Related to Redmine - Defect #2824: MySQL Deadlock Error when showing a big repository New 2009-02-24

History

#1 Updated by Eric Davis almost 11 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.

#2 Updated by Nicolas Chuche almost 11 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.

#3 Updated by Eric Davis almost 11 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.

#4 Updated by Etienne Massip over 8 years ago

  • Category set to SCM

#5 Updated by Gabriel Mazetto over 6 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.

#6 Updated by Toshi MARUYAMA about 4 years ago

  • Related to Defect #2824: MySQL Deadlock Error when showing a big repository added

#7 Updated by Go MAEDA over 3 years ago

  • Description updated (diff)

Also available in: Atom PDF