tSystem sans attente de fin [Résolu]

[Deirdrhil]

Bonjour à tous,

J'ai tenté aujourd'hui de faire un petit job tout bête :

tFileList ----- iterate ------ tSystem

L'idée, c'est de lister donc un répertoire, et pour chaque fichier du répertoire d'exécuter un petit programme (ou batch puisque je testais sous windows). Mais surtout, je souhaite que chaque fichier soit traité indépendamment du précédent, sans attendre la fin de l'exécution du tSystem précédent.

Malheureusement, je n'y suis pas parvenu avec juste un tSystem, en tentant des "cmd /C start calc.exe" par exemple pour chaque fichier : la calculatrice se lance bien, mais le job reste en attente de sa fermeture pour faire sa prochaine itération.

En cherchant un peu, j'y suis parvenu avec une petite bibliotheque externe et en passant par un tJava (merci Adiguba et son article ). Mes calculatrices s'ouvrent toutes en même temps ou presque. En tout cas, sans attendre que la précédente ne soit fermée


Mais je souhaiterai savoir s'il est possible de le faire naturellement dans Talend Open Studio, sans bibliothèque externe.

Auriez-vous une idée ?

[mgoudet]

Bonsoir,

en théorie, une itération prend fin que lorsque tout les autres composants ont terminés leur exécution.
Je ne pense pas qu'il soit possible (nativement sous TOS) de commencer une itération avant la fin de la précédente (mais je peux me tromper ).

Cordialement,

[Deirdrhil]

Oui c'est bien ce que j'en avais déduit, et j'avais au tout départ commencé avec un tRunJob (infructueux) d'où mon idée de passer un tSystem : je pensais pouvoir lancer un programme en tâche de fond, sans intéraction avec le job talend, afin de libérer le Iterate pour le fichier suivant.
Car si l'un de mes fichiers pose problème (un peu trop long à traiter, par exemple), il ne doit surtout pas bloquer les fichiers suivants.

[DevNico]

Bonjour,

Dans l'onglet component pour le lien iterate, il faut cocher l'option Enable parallel execution et mettre le degré de parallélisation souhaité.

Il lancera autant de thread que de degré défini. Et traitera l'ensemble des fichiers sur autant de thread en parallèle.

Nicolas

[Deirdrhil]

Ah oui tiens ... J'y avais pensé, mais je n'avais pas pensé à rendre dynamique ce nombre d'exécutions parallèles. Sans doute la fatigue ...

Donc en comptant le nombre de fichiers avant d'exécuter (en utilisant ((Integer)globalMap.get("tFileList_2_NB_FILE")) par exemple), ça a l'air de fonctionner. Ca me permettra de lancer autant d'exécutions en parallèles que de fichiers à traiter. Me restera à vérifier si un plantage d'un tSystem me plante tout le reste, mais en jouant avec les tDie je devrais pouvoir intercepter de toute façon.

Je testerai ça plus en détail demain

Merci bien Nico !

[DevNico]

Attention à l'utilisation du tSystem : je l'ai utilisé sous linux, et j'ai eu pas mal de soucis au niveau de l'utilisation mémoire car il fait un fork. C'est à dire qu'il duplique le processus courant pour exécuter la commande dans ce processus.
Ce qui veut dire que si ton processus de départ utilise une quantité de mémoire conséquente, ton nouveau processus va utiliser la même quantité.

Je te conseillerais donc de revenir sur ta première idée de tRunJob, qui devrait fonctionner sur la même stratégie.

Nicolas

[Deirdrhil]

Merci de l'info

Je pensais utiliser le tSystem pour lancer un nouveau processus indépendant, mais s'il fork avec les même paramètres mémoire, ça va en effet pas le faire.