Held messages: Long time waiating for response of the Mailman API
Hello,
We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is installed in a venv and deployed using Apache and uwsgi. This works quite well so far, only withheld messages cause us a problem: If we try to approve them via Postorius, the message is delivered to the list immediately, but the success message in Postorius takes a long time - on average the process hangs for three minutes until the message is no longer displayed. We have already adjusted the timeout in gunicorn.cfg, but this does not improve the situation. Are there any tips on how we can speed up the REST API? Or is it even a configuration error?
Greetings
Stephan
On 1/18/22 06:24, Stephan Krinetzki wrote:
Hello,
We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is installed in a venv and deployed using Apache and uwsgi. This works quite well so far, only withheld messages cause us a problem: If we try to approve them via Postorius, the message is delivered to the list immediately, but the success message in Postorius takes a long time - on average the process hangs for three minutes until the message is no longer displayed. We have already adjusted the timeout in gunicorn.cfg, but this does not improve the situation. Are there any tips on how we can speed up the REST API? Or is it even a configuration error?
There are two steps in handling the POST for a held message. The first step is accepting, rejecting or discarding the message. This is happening immediately.
The second step is handling the poster's moderation action based on the
choice from the Set member moderation dropdown in the view of the held
message. This is processed by the code at
<https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list....>.
If no selection has been made, the default value POSTed for
moderation_choice is no-action and that code is skipped. If it is one
of the choices Hold for moderation, Reject (with notification),
Discard (no notification), Accept immediately (bypass other rules)
or Default processing that is processed. So presumably a selection has
been made and processing is stuck on getting the member or setting the
member's moderation action.
Possibly the logs of your database manager will have information.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/24/22 15:06, Mark Sapiro wrote:
On 1/18/22 06:24, Stephan Krinetzki wrote:
Hello,
We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is installed in a venv and deployed using Apache and uwsgi. This works quite well so far, only withheld messages cause us a problem: If we try to approve them via Postorius, the message is delivered to the list immediately, but the success message in Postorius takes a long time - on average the process hangs for three minutes until the message is no longer displayed. We have already adjusted the timeout in gunicorn.cfg, but this does not improve the situation. Are there any tips on how we can speed up the REST API? Or is it even a configuration error?
There are two steps in handling the POST for a held message. The first step is accepting, rejecting or discarding the message. This is happening immediately.
The second step is handling the poster's moderation action based on the choice from the Set member moderation dropdown in the view of the held message. This is processed by the code at <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list....>. If no selection has been made, the default value POSTed for moderation_choice is
no-actionand that code is skipped. If it is one of the choicesHold for moderation,Reject (with notification),Discard (no notification),Accept immediately (bypass other rules)orDefault processingthat is processed. So presumably a selection has been made and processing is stuck on getting the member or setting the member's moderation action.Possibly the logs of your database manager will have information.
Some additional info.
By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If you are using gunicorn as a wsgi server, that is separate from the gunicorn serving the REST API and its config doesn't affect the REST API. The relevant config is mailman/config/gunicorn.cfg?.
Also, I doubt the issue is with the REST API per se, but rather it is in Mailman core's processing of the particular endpoint and if that is slow, it is most likely some kind of database issue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
On 1/24/22 15:06, Mark Sapiro wrote:
On 1/18/22 06:24, Stephan Krinetzki wrote: Hello, We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is installed in a venv and deployed using Apache and uwsgi. This works quite well so far, only withheld messages cause us a problem: If we try to approve them via Postorius, the message is delivered to the list immediately, but the success message in Postorius takes a long time - on average the process hangs for three minutes until the message is no longer displayed. We have already adjusted the timeout in gunicorn.cfg, but this does not improve the situation. Are there any tips on how we can speed up the REST API? Or is it even a configuration error? There are two steps in handling the POST for a held message. The first step is accepting, rejecting or discarding the message. This is happening immediately. The second step is handling the poster's moderation action based on the choice from the Set member moderation dropdown in the view of the held message. This is processed by the code at https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list..... If no selection has been made, the default value POSTed for moderation_choice is no-action and that code is skipped. If it is one of the choices Hold for moderation, Reject (with notification), Discard (no notification), Accept immediately (bypass other rules) or Default processing that is processed. So presumably a selection has been made and processing is stuck on getting the member or setting the member's moderation action. Possibly the logs of your database manager will have information. Some additional info. By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If you are using gunicorn as a wsgi server, that is separate from the gunicorn serving the REST API and its config doesn't affect the REST API. The relevant config is mailman/config/gunicorn.cfg?. Also, I doubt the issue is with the REST API per se, but rather it is in Mailman core's processing of the particular endpoint and if that is slow, it is most likely some kind of database issue. Hi Mark,
yes, we are using a local copy of the gunicorn.cfg. It is in the home directory of our mailman3 instance (like the mailman.cfg, same directory).
We will now look into the postgresql database - maybe there is an index missing or something like that. Thank you for help.
participants (2)
-
Mark Sapiro -
Stephan Krinetzki