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.
On pouvait le faire avant avec un bête available() (bon qui lui même était buggé dans certains cas mais j'ai oublié les corner cases depuis le temps et si ils existent toujours).
Tu peux tout mutualiser sur un seul thread. De toute facon quitte a écrire du code complexe que tu vas passer 10 plombes à stabiliser alors que ca devrait être dans le JDK... Il te reste le reaper, mais effectivement ca ne va te poser problème que si tu fork pas mal.
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
Je suis entièrement d'accord avec ca.
Mon point était juste de tempérer l'enthousiame qui pouvait sembler naïf sur le ProcessBuilder. C'est juste une API de merde qui te masque presque tout ce dont tu as besoin pour faire ton job avec une implémentation bien pourrie aussi.
On arrive à faire des trucs qui marchouillent en lisant tout le code des VM et quand tout va bien. Quand tu forks des processus non controllés sur plusieurs systèmes différents c'est bien plus "rigolo".
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par ckyl . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 3.
Je suis entièrement d'accord avec ca.
Mon point était juste de tempérer l'enthousiame qui pouvait sembler naïf sur le ProcessBuilder. C'est juste une API de merde qui te masque presque tout ce dont tu as besoin pour faire ton job avec une implémentation bien pourrie aussi.
On arrive à faire des trucs qui marchouillent en lisant tout le code des VM et quand tout va bien. Quand tu forks des processus non controllés sur plusieurs systèmes différents c'est bien plus "rigolo".