Creo que uno de los dolores de cabeza más grandes que hay en Odoo es la configuración correcta del longpolling (hoy llamado websocket) y desde las versiones actuales las consideraciones empiezan a ser amplias. Esto no pretende ser una guía muy profunda pero si marcar una serie de "tips" o errores comunes que se cometen al momento de configurar esto, que nos darán de forma constante un horrible error en la consola: RuntimeError: Couldn't bind the websocket. Is the connection opened on the evented port (8072)
¿Para qué sirve el websocket?
Esto suele ser moneda corriente: no me funciona y no entiendo que diferencia hace en mi Odoo, ¿para qué gastar neuronas en hacerlo funcionar? Bueno, sentimiento compartido, pero no es tan fácil. Al trabajar en un entorno de desarrollo, es normal que usemos una configuración de 0 workers, y todo va a funcionar de maravilla. El problema es que al momento de salir a producción vamos a querer activar el multi-hilos (necesario para ejecutar acciones en segundo plano en paralelo), elevaremos los workers al número indicado según cores del servidor y automáticamente vamos a tener que pasar por el proxy. Además de un dominio, el proxy va a redirigir al puerto de odoo (típicamente el 8069) y al del websocket (típicamente el 8072 salvo que lo cambiemos). Si al configurar todo vemos en nuestro log el error de "Couldn't bind the websocket", sabremos que algo no está bien configurado, ergo el multi-hilos no se activa, ergo podemos tener fallas del sistema en automatizaciones o mensajería.
El Proxy
Generalmente si tenemos configurado los workers en un número mayor a 0 y el parámetro proxy en True, y sigue con errores, el problema está con el proxy en sí. Aclaro que esta explicación será sobre NGINX, porque es lo que usamos el 99% de las veces; pero es aplicable a Apache, solo hay que traducir. Lo primero es la estructura básica, esto es muy a medida de cada entorno, pero lo voy a explicar como si lo lo conectara al dominio "midominio.ar":
server {
listen 80;
server_name midominio.ar;
add_header Strict-Transport-Security max-age=2592000;
location / {
proxy_pass http://localhost:8069;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Host $host;
proxy_redirect off;
proxy_request_buffering off;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
send_timeout 36000s;
client_max_body_size 10240m;
}
location /websocket {
proxy_pass http://127.0.0.1:8072;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Para no copiar y pegar sin entender lo que se está haciendo, es importante comprender un par de cosas de esta estructura. La primera es que no sirve para cualquier tipo de DNS, acá estoy considerando que se viene desde CloudFlare y por eso se escucha sobre el puerto 80 pero el root hace proxy con https, porque CloudFlare ya coloca el certificado SSL. Es lo primero a tener en cuenta para saber como lo vamos a armar, los parámetros en si suelen ser los mismos (alguno más o alguno menos) pero siempre contemplar primero el DNS.
Después, siempre recomiendo tener la estructura prolija y legible para ver donde puede estar el error. A grandes rasgos tenemos dos bloques de location, uno hacia el root que redirige al 8069 (esto es en esencia Odoo) y el otro hacia /websocket que redirige al 8072. Estos puertos tienen que estar abiertos y si se van a usar otros tienen que configurarse desde el odoo.conf. Después, siempre revisar que ambos bloques estén separados, en ocasiones he visto que se coloca el websocket dentro del root y eso es lo que da el error.
¿Y si sigue sin funcionar?
Si al configurar todo esto seguimos viendo el error en el log puede deberse a muchos factores particulares del servidor, DNS y proxy que tenemos montado. Para empezar, ante la duda recomiendo revisar la apertura de puertos desde el propio server, a veces si estamos en un servicio de cloud los vemos habilitados pero no se habilitó realmente por múltiples factores (quizás pide reiniciar el cloud entero, quizás es un reporte a soporte).
También recomiendo revisar bien el DNS, esto es un mundo a parte. Por ejemplo en CloudFlare a veces se recomienda limpiar el caché de los dominios para que pueda dejar de tomar el websocket.js de lo que tiene en caché (esto se hace para mejorar el rendimiento de los sitios al cargar). Al hacer esto, recuerden siempre esperar, lo más probable es que al momento les siga dando el error en el log pero con el paso de las horas se termine de limpiar y ya quede bien. La paciencia es una virtud.