Lors de l'envoi d'un courrier via javamail, un socket est ouvert sur le serveur smtp. Maintenant, nous avons eu le cas, que la connexion du serveur de messagerie est tombée alors que la connexion était encore en vie et que javamail attendait le serveur (l'analyse du spam prenait quelques secondes). Par conséquent, la connexion TCP n'a jamais été vraiment fermée et le client bloqué.Javamail ne ferme pas complètement la socket au moment de l'expiration
Nous avons donc décidé d'utiliser les délais d'attente javamails, ce qui fonctionne - le client lève une exception après l'heure spécifiée. Cependant, la connexion tcp n'est PAS correctement fermée (netstat -np montre toujours la connexion comme "ESTABLISHED"). Seulement après avoir appelé System.gc(), le socket est fermé.
Ceci est un problème, parce que gc() est garantie avant toute OOM-exception est levée, mais pas avant que le FD-limite est atteinte ...
cela peut être contournée en quelque sorte, ou est-ce un bug javamail?
système affecté: Linux (Debian Squeeze), Sun JDK 1.6.0.20 (avec -XXUseSSE = 3), javamail 1.4.3
Les dépassements de temps de lecture ne sont pas nécessairement fatals. Ce serait une erreur pour JavaMail de décider autrement et de fermer la connexion. C'est ta décision. – EJP
Si je spécifie un délai d'expiration, la bibliothèque respecte ce délai, annule la lecture et renvoie une exception. Du point de vue de Java, tout va bien. Seule la prise n'est pas fermée. Seulement après une collecte de place, le socket est libéré. Cela signifie que la bibliothèque manque un appel à "close()" ... Je dois être capable de protéger les ressources système et de libérer des sockets même sans faire un gc() manuel - spécialement car cela pourrait être désactivé. –