Rails: Si necesitas callbacks, workers y estás pensando en arrays de objetos……..aquí te dejo las claves para entenderlo!

He estado trabajando en un proyecto express dentro de ASPgems, que consiste en desarrollar una idea y el compromiso de entregarlo en producción en una semana. No sé si otras empresas disponen de esta oportunidad en la que poder participar, pero yo me apunté sin dudarlo, es una experiencia muy buena, ya que te enfrentas a situaciones que en ocasiones los tienes resueltos y este tipo de reto, hace que vuelvas a tener la alerta activa. Os voy a contar en que consiste el proyecto para poder entrar en situación y entender de lo que intento explicar y las soluciones que he aplicado.

La aplicación consiste en saber que gemas está utilizando cada proyecto que se de de alta en la aplicación, por lo que debe disponer de una interfaz de usuario, para dar de alta un nombre de proyecto, una URL del repositorio para poder saber en su Gemfile las gemas que utiliza y leer en RubyGems  más información sobre ellas.

Según estaba planteando los retos de los puntos claves de la aplicación, lo primero que debía solucionar es, cómo interactúa esa interfaz de usuario y el tiempo de proceso que se lleva el disponer de toda la información de lectura del Gemfile, así como el reto en tiempo de ir a buscar cada una de las gemas a Rubygems y conseguir la información adicional de la descripción y el resumen. Esto plantea dos tipos de accesos externos que se necesitan para obtener información, uno al repositorio del proyecto y el otro a Rubygems y eso lleva un coste que hay que medir y tratar.

Sidekiq, una gema y solución a un problema concreto

En esta ocasión vamos a hablar de Sidekiq, una gema muy interesante, en la que se me ha planteado un problema y voy a contar cómo lo he resuelto. El tema de la elección de Sidekiq ha sido por el tratamiento de los workers mediante threads y no mediante procesos forks, como es el caso de utilizar Resque. Si quieres ver ambas gemas, te dejo los links de Sidekiq y de Resque, pero veamos algunas aclaraciones antes.

Los Forks: cuando trabajamos con procesos Forks lo que estamos haciendo es crear una copia completa del proceso en si mismo y podríamos decir que copiamos el espacio de direcciones y de todos los descriptores.  Sin meterme en mucha más profundidad y como parte de una aclaración en las posibilidades que puedes tener, si el lenguaje de programación (MRI Ruby) no admite el nivel kernel level threading, entonces esta es la única manera de difundir el trabajo a través de múltiples núcleos, ya que cada proceso se consigue un núcleo diferente. También ganas un poco de estabilidad, pero por contra tienes la posibilidad de que si un proceso padre se cuelga los procesos hijos de este, quedan en estado zombies.

Los threads: podríamos decir que consumen menos recursos, ya que comparten el espacio de direcciones, la memoria y permiten tener una comunicación más fácil, si hacemos una comparación con la comunicación entre procesos forks. El cambio de contexto entre los threads dentro del mismo proceso también es generalmente mucho mejor que los forks. Dependiendo del tiempo de ejecución que se utiliza, cualquier problema que pueda ocurrir con los threads (por ejemplo, necesidad de utilizar grandes cantidades de memoria para una tarea) pueden ser manejados por el recolector de basura en su mayor parte. Finalmente una ventaja es con respecto a los procesos zombies, es que no hay que preocuparse, ya que mueren en el momento que el proceso muere, evitando los procesos zombies.

El problema que se me ha planteado es el siguiente: