Community
Participate
Working Groups
Orion I am running a local Orion server. Somehow I got my repo into a state where the "Branches" and "Commits" sections of the git-repository page won't load. This prevents me from doing most Git operations. Steps are: 1. Go to "Repositories" page. 2. Click on my clone of "org.eclipse.orion.client". 3. Wait a few seconds. 4. JS errors appear in the console. The "Commits..." and "Branches..." sections never load. Console errors: > Error > arguments: undefined > dojoType: "timeout" > message: "timeout exceeded" > type: undefined > > DOMException > code: 11 > message: "INVALID_STATE_ERR: DOM Exception 11" > name: "INVALID_STATE_ERR" > ...
There's something funny going on with 2 of the network requests: http://localhost:8080/gitapi/branch/file/ac/ http://localhost:8080/gitapi/branch/file/ac/?commits=1&page=1&pageSize=5 They cause my server to consume 100% CPU for ~60 seconds. It seems like they do eventually finish, but the page never updates.
Created attachment 210068 [details] Clone showing the problem Here's a zip of my clone. It's about 6 months old. I've been modifying it from both Orion and msysgit.
Gosia this code was recently modified to add extra details about commits to the branch representations. We need to investigate it.
I just investigated it. I managed to reproduce it on Marks repository. This is my outcome: 1. The timeout is not thrown from list branches request it is usually thrown from some other requests that is not handled as a task. The problem is that listing branches takes some many resources that other typically short requests run too long. 2. Mark's repository has 4 remotes, 12 local branches, 241 remote branches 3. The longest portion of the request is doing those small logs (1 commit long) for every branch when listing branches, for some reason getting those logs for local branches is much faster when I remove 3 remotes from the repository and work on just one 4. Getting the remote for local branch takes some time too Optimizing getting those small logs would fix the problem for sure. Adding paging to remote branches is not a bad idea as well.
(In reply to comment #2) > Created attachment 210068 [details] > Clone showing the problem A perfect test case Mark! Thanks for sharing this. Your setup showed few flaws in the way we construct git responses. Most of them have been fixed here [1], for others, less severe, I will open separate bugs. [1] 064ddf25864bbce2178bb1dcd8962a6ed62b2e5a
