Cuidado Con Modulo Mrwtracking

[Enrique Gómez]

Simplemente si alguien tiene el módulo de mrwtracking proporcionado por MRW.

 

Si resulta que el backoffice se os queda colgado es muy posible que este módulo sea el culpable ya que llama cada 5 minutos a un webservice que puede hacer que simplemente no podáis operar en el backoffice

 

Respuesta de MRW al problema

 

Conocemos el funcionamiento del módulo, pero es algo necesario que el módulo esté verificando constantemente el estado de los pedidos para poder hacer seguimiento y poder cambiar el pedido a estado enviado.

 

Pueden elevar el número de minutos necesarios para dar otra vuelta a la base de datos y comprobar qué pedidos de MRW han sido enviados. Tan sólo  deberían aumentar los minutos de 5 a lo que deseen y mitigaría algo el problema.

 

Reducir la base de datos eliminando pedidos obsoletos también ayudaría.

 

 

Mas que nada es para que no os volváis locos..

 

 

 

 

[serpega]

Mal programado y respuesta errónea

No se puede hacer esto. Han de poder habilitar un cron o una llamada AJAX para hacer esto, el admin se hace inviable.

Para colmo pongamos que tenemos 200 pedidos en curso ...

La web hace 200 llamadas al servicio web de MRW, en lugar de solicitar todas de golpe o en bloques.

Peor no se puede hacer

[Luisejo]

Hola @Enrique Gómez

Considero que el funcionamiento del módulo es correcto, te recomiendo subir el tiempo de ejecución de 5 minutos a 30, ya que notarás una mejora considerable.

@serpega en cuanto a lo que tú comentas, el funcionamiento no es el indicado. Da igual si hay 1 pedido o 200, la llamada siempre es una sola, y en ella, se recupera el dato de cada uno de los pedidos en curso. Hablo sin tener conocimiento de como funciona el módulo, pero seguro que es así.

Y ojo, que yo no tengo nada a favor de MRW ni de ningún otro servicio de mensajería.

[serpega]

Hola @Luisejo

Coméntale a un cliente, que cada 5 minutos, aleatoriamente le va a tardar 5 minutos en guardar un producto, en ver un pedido o cualquier otra pantalla del admin.

Eso no está bien, las tareas de backend no se las ha de comer el usuario de la web, se hacen por detrás sin intervención ninguna. Al menos debería dar opción de configurar un cron.

Supongo que en una tienda con pocos pedidos pendientes no pasa nada, pero si hay mucho pedido es imposible trabajar.

Y sí, te lo confirmo, en el caso de mi cliente son 236 llamadas al SOAP al api de MRW (supongo que una por cliente). He tenido que pasarle un profiler de sistema para averiguar qué módulo era el que se comía todo el tiempo, pues el cliente estaba hasta el gorro.

Si al alguien le vale, he modificado el módulo de forma rápida para que sólo en el dashboard del admin llame a MRW

Fichero: modules/mrwtracking/mrwtracking.php Función: hookBackOfficeFooter

 public function hookBackOfficeFooter($params)
    {

        if(isset($_GET['controller'])){
                if($_GET['controller']!='AdminDashboard') return;
        }

 

[gusman126]

El hacer llamadas sin poder activar o desactivar la opción, y no añadirla a una orden cron, es una barbaridad, si todos los modulos que sincronizan con los marketplaces o con webservices lo hicieran seria imposible hacer nada.

Una vez dicho esto.

Gracias por el aviso y posibles soluciones

[Enrique Gómez]

On 12/31/2019 at 8:35 AM, serpega said:

Hola @Luisejo

Coméntale a un cliente, que cada 5 minutos, aleatoriamente le va a tardar 5 minutos en guardar un producto, en ver un pedido o cualquier otra pantalla del admin.

Eso no está bien, las tareas de backend no se las ha de comer el usuario de la web, se hacen por detrás sin intervención ninguna. Al menos debería dar opción de configurar un cron.

Supongo que en una tienda con pocos pedidos pendientes no pasa nada, pero si hay mucho pedido es imposible trabajar.

Y sí, te lo confirmo, en el caso de mi cliente son 236 llamadas al SOAP al api de MRW (supongo que una por cliente). He tenido que pasarle un profiler de sistema para averiguar qué módulo era el que se comía todo el tiempo, pues el cliente estaba hasta el gorro.

Si al alguien le vale, he modificado el módulo de forma rápida para que sólo en el dashboard del admin llame a MRW

Fichero: modules/mrwtracking/mrwtracking.php Función: hookBackOfficeFooter

 public function hookBackOfficeFooter($params)
    {

        if(isset($_GET['controller'])){
                if($_GET['controller']!='AdminDashboard') return;
        }

 

Efectivamente, lo normal sería en este caso programar un cron que llame a un script (como hacen cientos de módulos) para que realice la tarea que hoy se hace en el hookBackofficeFooter. Al ejecutarse en el mismo hilo sin ningún timeout razonable (salvo el timeout del hosting), te bloquea el backoffice. Si se ejecuta en el cron, si el WS no funciona, acabará dando un timeout (típicamente a los 5 minutos, pero es configurable) pero no afectará en nada ya que se ejecuta en su propio hilo.

Porque no lo hacen? Yo creo que hay muchos hostings que incluso no ofrecen la posibilidad de programar crons (o hay que pagar un extra) y MRW no quiere una capa extra de problemas de configuración (suelen dar soporte) porque la mayoría de gente no sabe como configurarlo en el panel de control que tenga.

A parte que estar pululando por el backoffice no es la mejor manera de controlar que se ejecuten estas cosas.. si no entras al backoffice no se ejecuta..

 

 

Edited January 2, 2020 by Enrique Gómez (see edit history)

[Luisejo]

Pero señores.... ¿hemos leído bien?

Tengamos en cuenta lo que dicen los desarrolladores del módulo:

Cita

Pueden elevar el número de minutos necesarios para dar otra vuelta a la base de datos y comprobar qué pedidos de MRW han sido enviados. Tan sólo  deberían aumentar los minutos de 5 a lo que deseen y mitigaría algo el problema.

Yo no tengo ningún interés en apoyar a MRW, de verdad. Pero tan sencillo como cambiar 5 por 60 y listo.

En cuanto a esto... si que me parece tanto extraño como una barbaridad.

Cita

Y sí, te lo confirmo, en el caso de mi cliente son 236 llamadas al SOAP al api de MRW (supongo que una por cliente). He tenido que pasarle un profiler de sistema para averiguar qué módulo era el que se comía todo el tiempo, pues el cliente estaba hasta el gorro.

Gracias por la notificación.
Saludos.

[Enrique Gómez]

1 hour ago, Luisejo said:

Pero señores.... ¿hemos leído bien?

Tengamos en cuenta lo que dicen los desarrolladores del módulo:

Yo no tengo ningún interés en apoyar a MRW, de verdad. Pero tan sencillo como cambiar 5 por 60 y listo.

En cuanto a esto... si que me parece tanto extraño como una barbaridad.

Gracias por la notificación.
Saludos.

Si el servicio web no funciona, si cambias 5 por 60 se te atascará la tienda a los 60 minutos desde la última llamada en lugar de cada 5 minutos. Suponiendo que el Servicio Web esta caído, si ha pasado una hora de la última llamada, el resto del día no podrás entrar al backoffice.

Y no es a los 60 minutos de duración de la conexión del backoffice, es a los 60 minutos desde la última llamada, vamos que se te atascará igualmente.

También puedes poner 1000000 minutos y problema solucionado! Ah si, pero ahora no se esta llamando a la funcionalidad y no se están actualizando los pedidos. Es decir, que la solución es eliminar la funcionalidad.. O programar un cron que es lo mas lógico.

 

En cualquier caso el aviso original del post es de hace casi 4 años mas que nada para que la gente lo tuviese en cuenta, pensaba que lo habrían modificado pero veo que no..

Y por cierto la edición, al menos en el momento de la incidencia, de los 5 minutos es manual en el código fuente ($dif['min']) > 5)

Aquí la función original del módulo

 public function hookBackOfficeFooter($params) 
    {
        $fecha = Configuration::get($this->rename . 'LAST_EXECUTE_MRW'); 
        $dif = $this->getTimeDif($fecha);
        $this->writeTolog('hookBackOfficeFooter:-> Entramos en el hookBackOfficeFooter');
        $this->writeTolog('hookBackOfficeFooter:-> $fecha = ' . $fecha);
        $this->writeTolog('hookBackOfficeFooter:-> $dif = ' . $dif['min']);
        if ((int) ($dif['min']) > 5) 
        {
            if ($this->debug_activo == '1')
                $this->writeTolog('hookBackOfficeFooter:-> Entramos en el HOOK. Hace ' . (int) ($dif['min']) . ' minutos que se ejecutó la última vez');
            $this->executeGetTrackingMRW();
            Configuration::updateValue($this->rename . 'LAST_EXECUTE_MRW', $dif['lastTime']);
        }
    }

 

Edited January 3, 2020 by Enrique Gómez (see edit history)

[gusman126]

hace 12 minutos, Enrique Gómez dijo:

En cualquier caso el aviso original del post es de hace casi 4 años mas que nada para que la gente lo tuviese en cuenta, pensaba que lo habrían modificado pero veo que no..

 

No lo habia visto, o no hubiera continuado .

Pero si dices que sigue igual , es una barbaridad que no lo hayan cambiado en este tiempo

[Enrique Gómez]

3 minutes ago, gusman126 said:

No lo habia visto, o no hubiera continuado .

Pero si dices que sigue igual , es una barbaridad que no lo hayan cambiado en este tiempo

Deduzco que no lo han arreglado por la respuesta del 30 de diciembre de @serpega.

Estos problemas de acceso a  APIS de terceros no son raros, incluso hubo una época que las conexiones de prestashop en el backoffice a la api de addons fallaba.

Por eso sacaron una librería "CIRCUIT BREAKER LIBRARY" para la 1.7

https://build.prestashop.com/news/resilient-php-applications/

[ferran.herrero]

Yo acabo de instalarlo y en cuanto lo he configurado, ha empezado a ralentizar el resto de mi tienda... eso si, no os dejéis engañar si lo instaláis y mientras no está en producción funciona correctamente, puede ser que en modo test el módulo no haga llamadas a la web de MRW.

 

Creo que prefiero seguir haciendo envíos desde su plataforma de forma manual antes de tener este módulo instalado.

Edited January 3, 2020 by ferran.herrero (see edit history)

[Iván Ros Navarro]

Buenas tardes.

A mí me pasó ayer. No han cambiado mucho, no. No veas para descubrir que era el módulo de MRW. No muestra error ni deja rastro en logs. Lo ponía en modo DEBUG y seguía igual y no me llegaba a añadir nada a los logs.

Tuve que contratar a un experto en Prestashop y tras horas y horas llegamos a ver que mrwtracking hacía peticiones y no le devolvía nada y esperaba hasta el límite de tiempo. Si le pones límite 2 horas, estará 2 horas y te saltará el 'Connection timeout'.

He intentado modifciar el código del mrwtracking pero no hay forma de hacerlo funcionar ni de que solo se muestre en el controller AdminMrwController (para intentar "controlarlo"). Sigo a la espera de MRW para que me den solución. Mientras, mi solución es dejar activo el módulo mrwcarrier para poder seguir creando etiquetas y el de mrwtracking lo he dejado renombrado a la espera de noticias. Tampoco es que me haga especialmente falta, pero está bien saber qué pedidos están entregados sin tener que ir su web.

[serpega]

El experto en prestashop que detectó el fallo no debería tener problemas en cambiar el código para que funcione bien.

En mi caso, creo que lo cambiamos para que sólo lo haga en el admin, cada 30 min máximo una vez.

Es una solución chapucera pero barata y rápida

[Enrique Gómez]

Se trata de una versión vieja en 1.6 pero diría que tiene que funcionar en cualquier módulo mrwtracking.

El módulo desactivado o "desenganchado" del hookBackOfficeFooter para que no se ejecute automáticamente y  de problmeas

Luego se mete este fichero cron.php y se programa un cron que se ejecuta en paralelo y no "atasca" la web cada X tiempo, si el cron da un timeout no hay problema. El cron solo llama al hookBackOfficeFooter

La url con una clave de seguridad que se puede cambiar en el código fuente de forma sencilla

tu_web/modules/mrwtracking/cron.php?token=CLAVE_SECRETA

if ($sToken == 'CLAVE_SECRETA')

cron.php