L'article que tu cites dit que l'API ProcessBuilder est moche et pleine de pièges. C'est vrai. Mais elle est utilisable quand on est obligé de lancer un fils en Java. Même si je reconnais préférer le faire en C qu'en Java.
Depuis Java 5 c'est possible avec un thread par fils. Les flux sont pas selectables mais on peut faire des i/o avec timeout dessus alors on s'en sort. D'ailleurs c'est pas on peut mais il faut, pour les raisons cités dans ton article (pour pas se le faire bourrer d'un coup en mémoire à la mort du process) et pour d'autres (pour pas freezer le fils).
Ok un thread par fils c'est beaucoup si tu comptes avoir des centaines ou des milliers de fils mais dans le cas présenté ici (lancer quelques batches en parallèle) je continue à trouver que c'est un moindre mal par rapport à se retrouver avec un batch qui OOM la JVM et et plante les autres batches. Quand c'est pas pire qu'un OOM (parce qu'encore un OOM c'est la roulette russe, t'as de grande chance de pas tomber sur une balle et que l'exception libère masse mémoire ou les autres batches).
Après si les flux étaient selectables ont pourrait mutualiser un fils sur plusieurs processus, ou au moins éviter l'inélégance de faire des read avec timeout alternativement sur out et err. Certes. Ça ne serait pas pour me déplaire.
Perso j'ai fait en Java 4 et en Java 5 (ou 6 je sais plus mais ça n'a pas d'importance de ce point de vue 6 = 5).
Avant Java 5, tu pouvais pas lire les flux avec timeout du coup t'avais le choix entre ne pas lire les flux et prier pour que le fils ne remplisse pas les buffers et ne se freeze pas, ou bien ne pas pouvoir tuer le fils s'il est trop long car tu étais bloqué dans la lecture des flux, ou encore avoir 3 ou 4 threads (je sais plus) juste pour gérer un flux.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 0.
L'article que tu cites dit que l'API ProcessBuilder est moche et pleine de pièges. C'est vrai. Mais elle est utilisable quand on est obligé de lancer un fils en Java. Même si je reconnais préférer le faire en C qu'en Java.
Depuis Java 5 c'est possible avec un thread par fils. Les flux sont pas selectables mais on peut faire des i/o avec timeout dessus alors on s'en sort. D'ailleurs c'est pas on peut mais il faut, pour les raisons cités dans ton article (pour pas se le faire bourrer d'un coup en mémoire à la mort du process) et pour d'autres (pour pas freezer le fils).
Ok un thread par fils c'est beaucoup si tu comptes avoir des centaines ou des milliers de fils mais dans le cas présenté ici (lancer quelques batches en parallèle) je continue à trouver que c'est un moindre mal par rapport à se retrouver avec un batch qui OOM la JVM et et plante les autres batches. Quand c'est pas pire qu'un OOM (parce qu'encore un OOM c'est la roulette russe, t'as de grande chance de pas tomber sur une balle et que l'exception libère masse mémoire ou les autres batches).
Après si les flux étaient selectables ont pourrait mutualiser un fils sur plusieurs processus, ou au moins éviter l'inélégance de faire des read avec timeout alternativement sur out et err. Certes. Ça ne serait pas pour me déplaire.
Perso j'ai fait en Java 4 et en Java 5 (ou 6 je sais plus mais ça n'a pas d'importance de ce point de vue 6 = 5).
Avant Java 5, tu pouvais pas lire les flux avec timeout du coup t'avais le choix entre ne pas lire les flux et prier pour que le fils ne remplisse pas les buffers et ne se freeze pas, ou bien ne pas pouvoir tuer le fils s'il est trop long car tu étais bloqué dans la lecture des flux, ou encore avoir 3 ou 4 threads (je sais plus) juste pour gérer un flux.