Es normal que cada cierto período de tiempo nos pidan revisar la optimización de servidores donde un Odoo lleva funcionando. Nos ha tocado de todo, desde ver sistemas que aprovechan fuertemente la potencia del servidor hasta casos de errores bastante severos. Y entre los errores más comunes está la configuración del longpolling de Odoo, el cual da todo un conjunto de errores propios, y este caso trataremos de listar los más típicos.
¿Qué es el longpolling y por qué debería importarme?
Una de las razones por las cuales creo que hay tantos fallos es porque sin el longpolling odoo funciona dentro de todo bien. Es decir, no hay errores graves en la consola, no saltan errores en el servidor, el rendimiento del sistema es descente y odoo no lo trae habilitado por defecto. Brevemente, el longpolling es una técnica para evitar tener que preguntar por ciertas operaciones al cliente para revisar actualizaciones, en su lugar se disparan las mismas cuando una actualización es recibida, justamente gracias al longpolling. Se vuelve especialmente útil con la chat de Odoo, asi que si nunca pudiste hacerla funcionar bien, posiblemente se deba a eso. Por defecto, el longpolling opera sobre su propio puerto, el 8072 (podremos cambiarlo desde el odoo.conf).
Pero además el longpolling es fundamental para el correcto funcionamiento de acciones planificadas que se solapan, son requisito para activar el multiprocesamiento y ayudan a la construcción de ciertos controllers. A día de hoy no considero una instalación de Odoo completa sin el longpolling habilitado.
Exception: bus.Bus unavailable
Clásico, este error ocurre cuando el longpolling se habilita desde odoo con la opción de proxy_mode = True. Dicha opción es necesaria, ya que le dirá a Odoo que pase por un proxy, el problema es que si no hay proxy del otro lado nos saldrá ese error en el log constantemente. El servidor no funcionará peor, sin embargo el longpolling no estará habilitado tampoco. Para esto, primero asegurarse de tener varias cosas: un dominio apuntando al server, Nginx instalado con el proxy haciendo que el dominio apunte al puerto de Odoo (generalmente al 8069) y la configuración adecuada en el proxy para hacer pasar al longpolling por el puerto 8072. Debería quedar algo asi:
server {
listen 80;
server_name midominio.com.ar;
location / {
proxy_pass http://127.0.0.1:8069;
proxy_redirect off;
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;
}
location /longpolling {
proxy_pass http://127.0.0.1:8072;
}
}
Algunos detalles a consideración: el puerto 8072 debe estar abierto y aceptando conexiones, cuiden no colocar una barra al final en proxy_pass http://127.0.0.1:8072 ya que dará errores, y es preferible tener un certificado SSL instalado y hacer que escuche en 443 por temas de seguridad.
Pop up intermitente, Conexión perdida, Conexión restablecida
Lo anterior mencionado debería alcanzar para tener bien configurado el longpolling, pero hay un detalle. Muchas veces al finalizar con esta configuración, al recargar Odoo en el backend, saltará un pop-up molesto que durará pocos segundos mostrando primero una Conexión Perdida y luego un cartel de Conexión Restablecida. Perdí la cuenta de las veces que vi este error.
Primero que nada, en modo desarrollador dirigirse a Ajustes > Técnico > Parámetros del sistema y buscar la key web.base.url. Asegurarse que dicho parámetro esté con el dominio previamente configurado, no que diga localhost:8069, 0.0.0.0:8069, 127.0.0.1:8069 ni ninguna cosa rara. El dominio principal que se usará para el Odoo.
Si el problema persiste, comprobar que en el archivo odoo.conf estén configurados los workers. Esto es tan simple como que una línea diga: workers = 0. Aunque acá hay que entender que deberían ser la cantidad de workers de acuerdo a los recursos del servidor. La cuenta es sencilla, se multiplica por 2 la cantidad de Cores y se le suma 1. Así en un servidor de 2 CPUs tendremos 5 workers. Luego de eso reiniciar Odoo. Esto también activará el multi-procesamiento.
Si aun así el cartel sigue saliendo, y la configuración del proxy es correcta, el único error que queda verificar es la apertura del puerto 8072. Dependiendo el proveedor del VPS, muchas veces ese puerto no se abre bien. En AWS hay que abrirlo desde una regla de seguridad, si el VPS es particular puede que se requiera solicitarlo. Acá será muy variable dependiendo el proveedor.
