Gitea: Gitea doesn't open more than 5 tabs in browser

[lakostin]

• Gitea version (or commit ref):
  1.12.0
• Git version:
  2.17.1
• Operating system:
  Ubuntu 18.04.3 LTS
• Database (use [x]):
  
  
  
  • [x] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist:

Description

I open pull request with multiple commits, then i open 5 new tabs in browser with each commit. Everything is ok. When i open the sixth tab and further they hang with message "Waiting for available socket..." until i close one of the previously opened tabs.
It can be reproduced in any browser.
What can this be connected to?

Screenshots

[lunny]

can't reproduce in https://gitea.com

[lakostin]

Updated description.

[Wuszek]

@lakostin
Just checked myself, Gitea 1.12.0, GIT 2.26.2, MySQL, hosted on Synology.
Created PR with >5 commits, opened PR and each commit multiple times. No issues.

[lakostin]

I have this isssue on multiple instances and even on different versions. All served by docker btw

[ChaseHall]

Can confirm, opening any new tabs after 6 have loaded for me results in awaiting for socket. Hosting on Docker as well.

[dexterxx-pl]

I had same issue here, just after updating to v1.12.
It's not related just to PR's - in my case I've just opened new tabs of issues of my project - loading just stucks... and it stucks for many minutes.

CPU usage stays at typical level, logs shows that database (MySQL in my case) also respond in typical time.

Now I've just figured out, that restarting gitea didn't solved problem, but restarting proxy (apache2) does.

After restarting I cannot now reproduce it :-1:

@lakostin are you using proxy at front of gitea?

[ChaseHall]

@dexterxx-pl Tried restarting my proxy in front of gitea to no effect.

[lafriks]

I think it is related to events endpoint that uses sockets for getting events about new notifications. We should probably somehow limit sockets count per user probably

[deptyped]

Same problem. But I could not reproduce this issue without a reverse proxy server (nginx in my case).
By the way, in Firefox pages stop loading after five clicks on the site in one tab.

UPD: Using http2 in nginx solved the problem

[zeripath]

Yeah I suspect this is EventSource issues.

[zeripath]

So I don't think this is the server holding things up but rather the browser. It looks like Firefox is blocking instead of just failing out.

[confusedsushi]

I can confirm this. It happened first after upgrading to 1.12. I am running gitea on Windows 10 2004 with an apache reverse proxy on Ubuntu 18.04.

I am able to reproduce this with Firefox and Chrome.

[zeripath]

Can anyone reproduce this on try?

[Governa]

Can anyone reproduce this on try?

It seems I do. Both in Firefox and in Chromium.

I just have to Login and from the Dashboard open multiple commits in tabs. If then I click on "View source" it will not load until I close enough(about 5 tabs are left open) tabs.

It seems to be about 5 tabs in each browser, as I could test Chromium while Firefox tabs were still open.

[lakostin]

Reproduced also in Gitea Version: 1.12.1 running with systemd.
Do not use any proxy server in front.

[flozzone]

Also Reproducible

version: 1.12.1
proxy: apache 2.4
env: docker container

• 5-6 clicks and gitea hangs, but when I open a private window and login, gitea works and is accessible again.
• Then I tried to reproduce this issue within a private window -> no chance
• Its interesting that in the debugger inside a private window I can see connections to /user/events (See the curl cmd below) while navigating, but not within a regular browser tab
• When doing the last click, no communications occur (Checked proxy access logs)

curl 'https://GITEA_HOST/user/events' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0' -H 'Accept: text/event-stream' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en-US; i_like_gitea=33dxxxxxxxxx270; _csrf=zIz1_5HrJzMfqWC4XXXXXXXXXXXXXXXXXXXXXOTQyNw' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

[mind-overflow]

This also happens while normally browsing Gitea, you do not need to open 5 different tabs at the same time. I have ran into this problem just by navigating through my commits and repository files, and have been running into it since at least version 1.11. I am now using 1.12.1 with the same identical problem.

Gitea is running behind an Apache2 reverse proxy, no docker. MySQL database. Ubuntu 20.04 LTS.

[42wim]

I can also reproduce this (on gitea 1.12.1), the /user/events keep pending.
Related to https://developer.mozilla.org/en-US/docs/Web/API/EventSource and HTTP/2.

I've patched my own gitea to disable javascript going to /user/events and everythings works fine now.
There should be an option to disable this when people don't have access to HTTP/2 loadbalancers.

[westhom]

I was seeing this issue in Firefox / Gitea 1.12.1, clicking around gitea a bunch would eventually cause requests to hang and never complete, essentially freezing the app. I noticed in the network debugger a lot of the requests were being fulfilled by the Service Worker.

I was able to fix my issue by going into about:debugging and unregistering the service worker for my gitea domain, then refreshing the tab. Now I can't reproduce the issue. The service worker appeared in the list after I re-opened for the first time, but all seems good now.

[ratuka]

Same here with Firefox and Chrome too.

[zeripath]

Sorry about this. This one is my fault.

There is a workaround:

[ui.notification]
EVENT_SOURCE_UPDATE_TIME=0

or use HTTP/2.0.

I've finally managed to hack up a fix and will push up a PR to push the EventSource stuff into a SharedWorker but it will need review.

---

Unfortunately the setting doesn't work due to a misunderstanding on my behalf. My suspicion was the EventSource would not open if you hit the tab limit not - that it would prevent opening new tabs - and although I tested with opening multiple tabs it didn't cause these problems.

This code has been part of master for quite some time - I don't understand why it was only on release of Gitea 1.12 that this problem was noticed. Presumably try runs on HTTP/2.0?

[mind-overflow]

Sorry about this. This one is my fault.

There are two workarounds:

[ui.notification]
EVENT_SOURCE_UPDATE_TIME=0

or use HTTP/2.0.

I've finally managed to hack up a fix and will push up a PR to push the EventSource stuff into a SharedWorker but it will need review.

EDIT: Looks like Firefox had cached some settings. I was still using HTTP 1.1 with my old session, however in incognito mode (and thus clearing the cookies too) switched me to HTTP 2.0, fixing the problem.

_Very weird, since my server allows HTTP 2.0 connections and I still manage to have this issue... Are you sure about the second fix? I'm starting to doubt that my configuration could be faulty, even though the Firefox dev console says I'm using HTTP 2.0..._

[ChaseHall]

[ui.notification]
EVENT_SOURCE_UPDATE_TIME=0

Doesn't appear to work for me, not sure if I just did something wrong.. Will try and figure out switching to HTTP/2.0.

[zeripath]

@ChaseHall try -1 instead of 0?

[ChaseHall]

@zeripath -1 just results in a 503. Nothing useful in docker logs about it..

[42wim]

I can second that, same issues as @ChaseHall

[zeripath]

@ChaseHall @42wim - sorry you're right - that's another bug with this too. :disappointed:

[zeripath]

OK #12095 will fix that too. Setting EVENT_SOURCE_UPDATE_TIME=-1 will disable all EventSources from that point.