-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Etherpad still crashs when when querying stats API with timeout #5343
Comments
There are two issues here that I'd like to address separately:
|
Sigh, I jinxed myself by saying that. It's not easy to fix. IIUC, what's happening is the MySQL server is so busy trying to enumerate all pads that unrelated queries over other pool connections are timing out. |
Thanks a lot for your constant work of improvement and support to help for our issues we have. Will #5347 apply in the next release? We would like to test it and give a feedback. |
Yes, it will be in the next release (1.9.0). Unfortunately, I think there's a low probability that PR will fix the issue for you. (It might, so it's still worth trying.) |
Okay, we keep trying and still hope 🤞 |
hey i would like to know one thing....if we contribute here is etherpad going to pay us ...and if it then whats the criteria how many pull req |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
We tried another time to get deeper in this problem. As we are using MariaDB/MySQL for Storage with MyISAM engine we looked what
After some improvements for our MariaDB instance we reduced the query time from ~90 seconds to ~53 seconds. But we were still not satisfied. So we noticed that we have ~18k Pads but 100.000.000 rows in MariaDB. So we stumble upon an old problem, that the sessionstorage still rapidly growths:
We cleaned around one year ago all entries starting with We will again clean the database from this entries and waiting for 1.9.0 release which hopefully fix the session creation. After we cleaned up the database I will bring new timings of our queries to compare. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Not stale. |
Describe the bug
This bug report relates to #5005.
If we try to fetch the
getStats
API after Etherpad starts, the whole process get killed (see the additional context). In #5005 we sawError: Query inactivity timeout
. Now it isError: Request aborted
. Nevertheless the process should not be terminated when this happens.Our Etherpad instance runs around 20k pads with a MySQL storage backend.
To Reproduce
Steps to reproduce the behavior:
curl -v --connect-timeout 60 --max-time 60 -s "localhost:9001/api/1.2.14/getStats?apikey=xxx"
Expected behavior
Etherpad should not crash if the HTTP Client closes the connection to the API Endpoint.
Server (please complete the following information):
node --version
): v14.18.2npm --version
): 6.14.15Additional context
The text was updated successfully, but these errors were encountered: