Pregunta de perfomance usando JavaMail

Hola buen día,

Estoy revisando una aplicación donde envían correos cada que surge un cambio en determinados procesos de la lógica de negocios. Realizando algunas pruebas de "desempeño" lo pongo entre comillas por que no realice una prueba de desempeño como tal. Pero bueno ese no es el tema aquí. Me di cuenta que en ocasiones se tarda demasiado en tratar de enviar el correo electrónico (se utiliza JavaMail para el envió) y se esta utilizando un servidor GlassFish con una sesión de JavaMail. Entonces mi pregunta es si estos tiempos se pueden mejorar enviando a una cola de mensajes el correo...

Explico mi idea:

Enviar un DTO del correo (un bean que se transforma a xml) a la cola de mensajes y que un EJB se encarga del envió de mensajes, de esta manera evito los largos tiempos de espera de la aplicación en terminar el flujo. Dando la experiencia al usuario que se termina el proceso mas rápido.

Alguien que me pueda dar su opinión al respecto, o que me recomendarían hacer...

De antemano muchas gracias por sus respuestas...

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

definitivamente

A fin de cuentas lo que necesitas hacer es enviar el correo en un hilo por separado, para que tu flujo actual no se detenga hasta que el correo sea enviado. Si necesitas saber el resultado del envío (si se pudo enviar, si no se pudo enviar, etc) entonces lo de la cola de mensajes suena bien, ya que podrías recibir una notificación si el mail no se puede enviar, para hacer algo al respecto.

Si no te importa tanto saber si el mail se envió o no, puedes hacer algo similar con un simple Executor de Java (ya sea de uno o varios hilos). Finalmente aunque el mail sea enviado, no hay garantía de que lo van a recibir; se puede perder en el camino, o no llega al destino final si su buzón está lleno o se le va al spam, etc.

Imagen de arterzatij

Gracias!

Creo que optare por lo del Executor creo que es la primera vez que lo escucho y dada que solo son notificaciones creo que es buena la opción :)

Mail en Cola

La estrategia mas comun para el envio de Mail, es que definas una Servicio de Cola (Queues) en donde depositas tu mensaje. Tendrias las tipicas dos colas de recepcion y de procesamiento, En la de recepcion vas a depositar (PUT) el mensaje (informacion del correo que quieres enviar) para que la cola de procesamiento tome ese mensaje y lo procese (envie el mail). Podriamos decir que es "asincrono" (que para mi punto de vista no lo es) por lo que tardas milesimas de segundo en depositar el mensaje y podrias continuar con el flujo de tu programa mientras el correo apenas se empieza a enviar o esta en proceso de envio, etc.

Esto es util en servicios donde tienes que enviar muchisimos mails, quizas un servicio de notificaciones de XXXX negocio que vigila cuentas vencidas... lo que sea.

Hay opciones, para MQ. Lamentablemente solo he utilizado el de IBM aunque he probado ligeramente el rabbitMQ que tambien suena muy buena opcion ... Alguna vez escuche de ZeroMQ pero no sé bien que fish con ese

Imagen de ezamudio

por qué no asíncrono?

Y por qué consideras que eso no es asíncrono?

Re: por qué no asíncrono?

Porque para eso se usan dos colas, una que se encarga exclusivamente de recibir (que es lo que tarda milisegundos) y la otra puede tardar incluso minutos (la de procesamiento). Cuando se inserta un mensaje en la cola de procesamiento se ha concluido la tarea de enviar el mensaje, ya será otro proceso el que inicie cuando se deposite dicho mensaje... Aunque si lo checamos todo a nivel de servicio, claro que esto puede resultar asincrono, pero hablamos del servicio completo o proceso mas no de la aplicacion porque son dos componentes diferentes.

Imagen de ezamudio

eso es...

es que eso es la definición de asíncrono... tu código pide que se envíe el mensaje y eso se hace en otro proceso, ya no te importa y se sigue ejecutando lo demás. Si es una cola o 10 es un detalle de implementación.