blocs de programme externe lors de son exécution par Runtime exec

Question

je tente de lancer une instance du programme VideoLAN à partir d'une application java. L'une des façons que j'ai essayé de le faire est montré ici:

Process p = Runtime.getRuntime().exec("\"C:\\Program Files\\VideoLAN\\VLC\\vlc.exe\" \"http://www.dr.dk/Forms/Published/PlaylistGen.aspx?qid=1316859&odp=true\" :sout=#std{access=udp,mux=ts,dst=127.0.0.1:63928}"); 

Si j'exécute la commande au-dessus du programme vlc sera lancé et commencera une opération de diffusion en continu (il passe par connexion, mise en mémoire tampon puis phases de streaming).

Lorsque la commande est exécutée par Runtime exec (ou ProcessBuilder démarrer), le programme vlc se bloque quand il a atteint la fin de la phase de mise en mémoire tampon. Si tous les threads du programme Java sont terminés/exécutés, le programme vlc passera à la phase de streaming. Le processus Java ne se termine pas tant que le processus vlc n'est pas fermé, ce comportement est donc le résultat d'une sorte de couplage entre les processus.

ont essayé d'exécuter la commande indirectement par écrit dans un fichier .cmd, puis l'exécuter, mais les résultats dans le même comportement.

Toutes les idées sur la façon dont je peux éviter la pendaison de processus externe?

Answer 1

Hmm, je pense serait que VLC votre tampon rempli stdout et est accroché dans un printf parce STDOUT attend ce tampon à vide.

Vous devez obtenir le flux pour la sortie du processus et de le lire (même si vous défaussez).

Je vous recommande de lire ce article

Sur la 4ème page est un bon exemple de la façon de lire les flux en fils de sorte que votre processus enfant ne bloque pas.

Answer 2

Ce site est fantastique :). Pour une raison quelconque, une approche que je pensais avoir déjà été essayée a soudainement commencé à fonctionner.

Le problème est que vlc écrit à son stdErrOut (non visible lorsqu'il est exécuté dans une invite). Il bloque alors une fois que le tampon de sortie est plein. Une solution consiste à avoir un stdErr redirigé vers stdOut et ensuite avoir un thread vide le flux d'entrée de l'objet de processus.

Il est cependant pas une solution optimale, puisque je besoin d'une bonne quantité de processus externes, et vous ne pouvez pas faire sans blocage d'E/S sur leur flux d'entrée. Expérimenter un peu avec un lecteur de service de minuterie en lecture vide pour un certain nombre de processus. D'autres suggestions sur la façon de découpler les processus pour éviter ce problème sont les bienvenues.