Discussion :

[PP(Team)]

Bonjour,

Je souhaiterais savoir si il est possible de "tuer" un Thread qui ne répond pas dans un "ThreadPoolExecutor" ?

Concrètement, je crée un pool d'éléments se connectant en IMAP, l'IMAP peut, parfois, ne pas répondre. Il me faut dans ce cas "tuer" le Thread afin qu'il puisse être réutilisé ultérieurement.

J'ai essayé divers éléments, mais sans succès.

Voici les différentes étapes :
- Création :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ArrayBlockingQueue<Runnable> queue = new ArrayBlockingQueue<Runnable>(5);
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(5, 5, 10, TimeUnit.SECONDS, queue);

- Ajout dans le pool :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
threadPool.execute(agentIMAP);

- Lorsque c'est terminé normalement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ArrayBlockingQueue<Runnable> queue2 = (ArrayBlockingQueue<Runnable>) threadPool.getQueue();
queue2.remove(agentIMAP);

- Tentative de "kill" manuel (qui ne fonctionne pas apparemment) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
// Kill du thread bloqué
long threadID = agentIMAP.getThreadID(); //Retourne l'ID du Thread utilisé par l'agent
Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
Thread[] threadArray = threadSet.toArray(new Thread[threadSet.size()]);
for (Thread thread : threadArray)
{
	if (thread.getId() == threadID)
	{
		if (!thread.isInterrupted())
                {
                      thread.interrupt();
		}
	}
}

Le problème est qu'avec ce type de code, lorsque l' "agentIMAP" est bloqué par l'IMAP (sur la connexion ou autre) alors le Thread attend que l'IMAP termine.

Y-a-t-il possibilité de réellement tuer le Thread et faire que le ThreadPool le recrée ?

Merci d'avance.

Cordialement.

[tchize_]

On ne peut pas tuer un Thread, c'est à lui d'avoir des processus pour s'arrêter de lui même.

Dans ton cas, si le Thread ne réagis pas à interrupt() (censé réveiller les appels bloquant comme le réseau) c'est cuit.

Il faut revoir ton Thread, la manière dont tu te connecte à IMAP par exemple.

[PP(Team)]

Bonjour,

Merci pour cette réponse.

Le problème est que je ne peux contrôler une action sur l'IMAP. J'ai beau mettre tous les timeout possibles certains IMAP ne respectent pas les timeout (pour une connexion non sécurisée) :
- mail.imap.writetimeout
- mail.imap.connectiontimeout
- mail.imap.connectionpooltimeout
- mail.imap.timeout

La seule solution est donc d'arriver à arrêter le Thread bloqué (qui se débloque au bout de 30 à 60 minutes ...).

Code de la connexion :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
Properties props = System.getProperties();
props.put("mail.transport.protocol", "smtp");
props.put("mail.store.protocol", "imap"); //ou "imaps"
if (useSSL == true)
{
	props.put("mail.imap.class", "com.sun.mail.imap.IMAPSSLStore");
}
else
{
	props.put("mail.imap.class", "com.sun.mail.imap.IMAPStore");
}
 
props.put("mail.imap.writetimeout", 30000);
 
if (useSSL == true)
{
	props.put("mail.imap.class", "com.sun.mail.imap.IMAPSSLStore");
	props.put("mail.imaps.timeout", 10000);
	props.put("mail.imaps.connectiontimeout", 10000);
	props.put("mail.imaps.connectionpooltimeout ", 30000);
}
else
{
	props.put("mail.imap.class", "com.sun.mail.imap.IMAPStore");
	props.put("mail.imap.timeout", 10000);
	props.put("mail.imap.connectiontimeout", 10000);
	props.put("mail.imap.connectionpooltimeout ", 30000);
}
Session session = Session.getDefaultInstance(props, null);
URLName url = new URLName("imap" /*ou imaps*/, hostName, port, INBOX, user, password);
IMAPStore store = new IMAPSSLStore(session, url);
try
{
	store.connect();
}
catch (MessagingException e)
{
...
}
catch (RuntimeException e)
{
...
}

Les "props" ne semblent pas tous être pris en compte, notamment ceux sur le timeout.

C'est pourquoi je souhaitais mettre en place un "manager" qui s'occupe que les Thread ne soient pas bloqué et les tuer éventuellement.

Cordialement.

[tchize_]

J'ai beau mettre tous les timeout possibles certains IMAP ne respectent pas les timeout (pour une connexion non sécurisée) :

Ce n'est pas le serveur, mais le client qui est supposé respecter ces timeouts .

La seule solution est donc d'arriver à arrêter le Thread bloqué (qui se débloque au bout de 30 à 60 minutes ...).

Pas possible, point!

Code de la connexion :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
if (useSSL == true)
{
	props.put("mail.imap.class", "com.sun.mail.imap.IMAPSSLStore");
	props.put("mail.imaps.timeout", 10000);
	props.put("mail.imaps.connectiontimeout", 10000);
	props.put("mail.imaps.connectionpooltimeout ", 30000);
}

Les docs que j'ai ne font pas mention d'un paramètre en "imaps", tu as un S en trop. Aussi, tu ne devrais pas référencer explicitement les classes en com.sun.xxxx

La liste des properties supportées par l'implémentation imap/imaps de javamail se trouve ici:

https://javamail.java.net/nonav/docs...e-summary.html

[tchize_]

Je pense que tu pourrais aussi fournir des SocketFactory custom, qui créent des sockets avec des timeout de lecture (je pense par exemple à appeler setSoTimeout sur la socket avant de la retourner)

[thelvin]

Les docs que j'ai ne font pas mention d'un paramètre en "imaps", tu as un S en trop.

En fait, cette même page écrit bel et bien, en tout petit, là où personne ne le lirait d'habitude, que si on utilise le protocole imaps, il faut bel et bien remplacer les mail.imap.truc par mail.imaps.truc
Jusqu'ici j'ai pas trop compris l'intérêt vu que j'ai pas trouvé comment utiliser plus d'un protocole avec la même conf'.

À noter que le protocole imaps ne va pas se choisir tout seul, 'faudrait peut-être penser à l'indiquer sinon, en effet, les mail.imaps seront purement ignorés.

Aussi, tu ne devrais pas référencer explicitement les classes en com.sun.xxxx

En l'occurrence ce sont des classes de la bibliothèque JavaMail, anciennement fournie par Sun, et qui ne fait pas partie de la bibliothèque Java de base.
Y a pas le choix, les classes sont dans ce package, et elles sont de toute façon publiques et publiquement documentées avec une JavaDoc dédiée.

[tchize_]

Je n'ai jamais eu besoin d'aller charger du com.sun explicitement pour utiliser javamail. On n'est censé utiliser que ce qui se trouve dans javax.mail. Le fait que les implémentation trainouillent dans com.sun.xxxx ne concerne pas le dev qui utilise javamail, il ne concerne que le dev qui modifie javamail.