<div dir="ltr"><div dir="ltr">Hello Valentin,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 3 nov. 2020 a las 17:08, Valentin Kleibel (<<a href="mailto:valentin@vrvis.at">valentin@vrvis.at</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
We are using kallithea with a postgres database on another server <br>
connected via ssl.<br>
It seems that celery in version 4 uses prefork in its worker pool model <br>
now, which leads to issues with such a database connection:<br>
<br>
```<br>
Task kallithea.lib.celerylib.whoosh_index[9c<br>
4dbbcc-b9e9-48be-9455-0bbcd8d251a2] raised unexpected: <br>
OperationalError('(psycopg2.Operational<br>
Error) SSL SYSCALL error: EOF detected\n')<br>
Traceback (most recent call last):<br>
   File <br>
"/mnt/webservices/virtualenv/kallithea-0.6.2/lib/python3.7/site-packages/sqlalchemy/eng<br>
ine/base.py", line 1277, in _execute_context<br>
     cursor, statement, parameters, context<br>
   File <br>
"/mnt/webservices/virtualenv/kallithea-0.6.2/lib/python3.7/site-packages/sqlalchemy/eng<br>
ine/default.py", line 593, in do_execute<br>
     cursor.execute(statement, parameters)<br>
psycopg2.OperationalError: SSL SYSCALL error: EOF detected<br>
<br>
The above exception was the direct cause of the following exception:<br>
(...)<br>
```<br>
<br>
We know that issues like this may arise from using prefork in uwsgi <br>
which we work around by setting lazy:true<br>
The reason for this is that when a database connection with SSL (as we <br>
use) is already established with a valid SSL context before a process is <br>
forked, the connection will cease to work as such a connection is <br>
stateful on both sides and cannot cope well with a fork.<br>
<br>
The only workaround to this we found is to setup celery to only use a <br>
single worker in production.ini:<br>
<br>
```<br>
celery.worker_concurrency = 1<br>
celery.worker_max_tasks_per_child = 5<br>
```<br>
<br>
But this has the drawback that long running tasks like indexing will <br>
block short running tasks like the creation of a new repository. Thus, <br>
this setting is undesired and worker_concurrency should be at least 2 on <br>
a production system.<br>
<br>
I tried to find an easy fix for this but it seems to need some changes <br>
to kallithea as long as celery and sqalchemy don't change to cope with <br>
this problem.<br>
<br>
I hope someone can help with this.<br></blockquote><div><br></div><div><br></div><div>I don't have answers but several questions.</div><div><br></div><div>Can you say more about how you set up the database connection? Do you do anything special here? Why is it different with SSL than without?</div><div>As far as I can see you would just need to give some extra parameters in the sqlalchemy.url setting in your ini file.</div><div>But your mail seems to suggest that you have a connection created upfront and would like this one to be reused?<br></div><div><br></div><div>Which are the uwsgi-related settings in your ini file? The 'lazy=true' setting is not a choice for Kallithea and should be enabled in any case.<br></div><div>Our uwsgi template for ini files gives this comment as clarification for 'lazy=true': "App *must* be loaded in workers - db connections can't be shared"</div><div><br></div><div>Did you use Kallithea in this mode successfully before, perhaps on an older version? Your mail seems to suggest that but I'm not sure.</div><div><br></div><div>Note: I found this related question: <a href="https://stackoverflow.com/questions/51466007/how-to-use-psycopg2-properly-in-a-prefork-celery-environment">https://stackoverflow.com/questions/51466007/how-to-use-psycopg2-properly-in-a-prefork-celery-environment</a> <br><div>but it does not involve sqlalchemy and does not really give immediate solutions.</div><div><br></div><div><br></div><div>Best regards,</div><div>Thomas<br></div><div><br></div></div></div></div>