¿Es aceptable dejar abierta la sesión de javamail Transport?

Question

Mi aplicación necesita enviar correos electrónicos ad hoc. Estoy usando getDefaultSession y getTransport de javamail para enviar el mensaje, y todo está funcionando como se esperaba.

Sin embargo, he notado que el envío puede llevar mucho tiempo, hasta siete segundos por envío. Si rompo los pasos hacia abajo, como esto:

Transport transport = session.getTransport("smtp"); 
transport.connect(); 
transport.sendMessage(msg, addresses) 
transport.close(); 

... Puedo ver que es la llamada connect() que toma casi todo el tiempo, cada vez.

Todos los ejemplos que he encontrado hacen esto: obtener un transporte, conectar, enviar, desconectar. Pero, por supuesto, todos son ejemplos de una sola toma, o el envío de grandes lotes de correos electrónicos en una sola llamada.

estaba pensando tan sólo pudiera dejar la conexión abierta, así:

Transport transport = session.getTransport("smtp"); 
if (!transport.isConnected()) 
    transport.connect(); 
transport.sendMessage(msg, addresses) 

(Hay una variación sobre el mismo, aquí: java mail keeping Transport object connected).

Tendré que cerrarlo eventualmente, en un gancho de apagado de algún tipo. Y podría tener que tener un respaldo (si la conexión se ha perdido pero el transporte no se da cuenta). ¿Pero hay alguna razón para no dejarlo abierto así durante la vida útil de la aplicación?

Gracias, Alastair

Answer 1

realmente no ven ningún problema en mantener una única conexión SMTP abierta, y se recomienda el uso de transporte de objetos para su reutilización conexión (véase la JavaMail tutorial).

Además, recomendaría mantener abierta solo una conexión smpt (a través de Transporte) en su aplicación, manteniéndola en una única instancia de administrador (es decir, utilizando un patrón único), evitando el costo final de mantener abierta una conexión diferente para cada componente que necesita enviar un mensaje.

Answer 2

Según @Bill Shannon 's (autor de JavaMail) respuesta aquí: Threadsafety in Javamail

Desde un transporte representa una conexión con un servidor de correo, y sólo un único hilo puede utilizar la conexión a la vez, una Transporte sincronizará el acceso desde múltiples hilos para mantener la seguridad del hilo, pero realmente solo querrá usarlo desde un único hilo.

Así que si va a utilizar una sola instancia de Transportmúltiples hilos (que suele ser el caso hoy en día), de hecho es bastante mala idea de punto de vista rendimiento. Probablemente sea mejor que desarrolle algún tipo de conjunto de instancias Transport utilizando ThreadLocal.