Discussion :

[Arthis]

Bonjour,

J'ai un nouveau problème sur lequel j ai commencé à me documenter mais je me disais que vous auriez peut être des pistes de recherche à me proposer sous forme de liens , ou d'astuces...

Alors voilá : J'ai un formulaire ou les personnes peuvent s'enregistrer et uploader une video. Jusque ici pas de souci, par contre je souhaiterais qu' à la fin faire quelques manipulation avec cette vidéo. Je pensais donc creer un thread asynchrone afin d'uploader cette video vers un nouveau serveur, lui laisser le temps de modifier ma video et ensuite la redispatcher encore ailleurs.

J'ai commencé a me detailler sur les threads, et j'ai vu que ceux ci se terminait lorsque la processus appelant se terminait lui aussi. Or j'aurais bien aime lors du traitement de ma page lancé un thread qui continuerait a survivre meme lorsque ma page aura été rendu au client.

D'avance merci pour vos suggestions,

[jacky01]

Salut, mon idée est peut-être bête mais je me lance

Vu que tu veux un thread asynchrone pourquoi ne pas faire un soft coté serveur qui tournerai en non-stop avec un ou plusieurs thread dedans. Et ainsi tu appel ton programme en lui passant l'url de ta vidéo par exemple ?

Si j'ai bien compris ta problématique cela pourrait être une solution

[Arthis]

mmh je crois que je preferais lancer un thread pour chaque video, il pourrait y en avoir plusieurs a traiter en meme temps, meme si ce nombre ne devrait aps etre prohibitif... sinon je devrais gerer les listes d'attentes et tout le toutim...

[jacky01]

Et bien dans ce cas tu fait un thread qui attend les paramètres, et à chaque vidéo qu'il reçoit (vidéo ou url peut importe) tu créer un nouveau thread qui va traiter ta vidéo, ainsi tu n'as pas à te soucié des files d'attentes ou de mutex.

[Arthis]

mhhh oui je comprends... Je pourrais lancer quelquechose lors de mon application start et l'arreter lors de l'application end.. C'est une bonne idée!

Je la garde en mémoire, je preferais dans un premier temps voir si iol n'y a pas moyen de le faire dans ma page tout de même.

Merci de l'idée en tout cas!

Je retourne dans mes recherches... (s'enfoui sous un tas de bouquins écrit en anglais...)

[npuzin]

Ce que tu veux faire c'est typiquement le role d'un "service windows".

Je te deconseille de faire ca avec un thread qui tourne ds le context de IIS. Ce n'est pas le role de IIS de faire ce genre de traitement lourd. Ca ne sera pas fiable et ralentira ton site web.

Le mieux serait de deposer le fichier a traiter dans un repertoire, et un service windows tournerait en tache de fond pour traiter tes fichiers puis les inserer dans ta base de donnees.

[Kaidan]

En utilisant ThreadPool.QueueUserWorkItem(..) ?

Le pipeline ASP.NET utilise le ThreadPool pour assigner un pool à chaque requête entrante, il faut donc faire attention de pas être en pénurie.

Le nombre de Thread maximum dans le ThreadPool peut être modifié (SetMaxThreads).

[Arthis]

Merci pour toutes ces réponses, je vais tatouiller tout ca maintenant..
a+

[Immobilis]

Salut,

Est-ce que tu pourrais nous faire part de ta résolution? Ça m'intéresse fortement.

A+

[Arthis]

A la fin, je suis revenu sur du monothread tout simple en contournant mes exigences de départ.

A un moment, j'ai utilisé la solution de Kaidan, qui me semblait la plus simple pour gérer ce genre de choses. Tout alors est pris en main ou presque par dot net, il y a juste à vérifier le nombre de thread disponible pour pas assécher ton serveur, car sinon tous les threads dispo sont en traitement batch et les utilisateurs ne peuvent pas avoir accès a ton site IIS.

Je crois que tu ne peux en effet sortir , en tout cas aisément, du domainapplication dans lequel tu te trouves pour lancer d'autres thread. Ce qui a la résultante que je décris avant.

Bon, prends tous ces renseignements avec beaucoup de recul, je n'ai pas eut le temps de pousser très loin mes investigations, et il y a peut être des choses que j'ai compris de travers.

Bon courage à toi en tout cas,