Discussion :

[alex61]

bonjour

voila j'ai un gros souci

j'ai créé une application qui fonctionner trés bien quand tout était en local pour mes test, mais je vien de la mettre sur le serveur et ca m'affiche cela

je ne met pas le code car il fait plus de 1000 ligne

Le CLR n'a pas pu effectuer de transition du contexte COM 0x1b0870 au contexte COM 0x1b09e0 pendant 60 secondes. Le thread qui possède le contexte/cloisonnement de destination est probablement en train d'attendre ou de traiter une opération très longue sans pompage des messages Windows. Cette situation a généralement des effets négatifs sur les performances et peut parfois entraîner le blocage de l'application ou une utilisation ininterrompue de la mémoire. Pour éviter ce problème, tous les threads STA (Single Threaded Apartment) doivent utiliser des primitives d'attente de pompage (par exemple CoWaitForMultipleHandles) et pomper de manière régulière les messages lors des opérations qui sont longues à s'exécuter.

je vous explique en gros le fonctionnement de cette application

- elle charge tout les document XML contenu dans un dossier ( une autre application les place la )
- extrait les donné des document XML pour les placer dans un une base de donné situé sur le réseaux local
- scanne la base de donné local pour envoyer des mail ( ou des fax)en fonction de son contenu avec un serveur smtp local
- dans certain cas elle créé des PDF et le place en pièce jointe
- génère un fichier XML qui contient une parti de la base de donné


voila

si quelqu'un pourrait me mettre sur des piste

je précise que je n'ai jamais gérer les thread je ne connait que la théorie la dessus

cordialement

[alex61]

j'ai mit des progressbar et des label qui indique l'action en cour

le problème viendrait d'ici

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Public Sub ScanUpdateControle()
        'envoie le mail a chaque entreprise qui viennet d enregistrer un ou plusieur epi grace au controle sur la table EntrepriseCliente
        Dim cn As New OleDbConnection
        cn = connexionBDD()
        Dim cmd As New OleDbCommand
        cmd.CommandText = "SELECT EC.ent_nom, EC.ent_auteur, EC.ent_courriel, EC.ent_fax, VA1.ver_date FROM EntrepriseCliente AS EC, VerificationAnnuelle AS VA1, VerificationAnnuelle AS VA2 WHERE EC.con_MailSynthese<>'1' And EC.ent_nom=VA1.ent_nom And VA2.ent_nom=VA1.ent_nom GROUP BY EC.ent_nom, EC.ent_auteur, EC.ent_courriel, EC.ent_fax, VA1.ver_date HAVING VA1.ver_date=max(VA2.ver_date); "
        cmd.Connection = cn
        cmd.Connection.Open()
        Using reader As IDataReader = cmd.ExecuteReader()
            While reader.Read()
 
                mailforSaveEPI(reader("ent_nom"), reader("ent_courriel"), reader("ver_date"), reader("ent_fax"))
 
                updatecontrolemail(reader("ent_nom"), "1")
 
                lalstcommercial.ajout(reader("ent_auteur"), "l'entreprise " & reader("ent_nom") & " a bien été mis a jour ")
 
            End While
        End Using
        cmd.Connection.Close()
 
    End Sub

humhum

[monsof]

Bonjour,
ça peut vous aider
http://www.developpez.net/forums/d54...k/#post3241895

[alex61]

en faite j'ai trouver
j'ai fait un boucle infinit a cause sur l'envoie de mail en cas d'exception

si l'envoie de mail ne marché pas ca envoyer un mail a l'administrateur


mais est-ce que quelqu'un pourrai m'expliquer simplement l'intérêt de thread ?

juste pour ma culture général

cordialement

[MABROUKI]

bonjour alex
mr jourdain fait de la prose sans le savoir.Il est innenarrable.Quand tu tapes sur word et tu demandes une impression à ton imprimante,diable tu consommes du "threading" sans le savoir et meme tu en jouis,tout en me semblant quelque part ingrat.
Quand tu lance un telechargement ou tu consultes plusieurs pages et qu'entretemps tu vaques à ta frappe ou dessine dans un autre logiciel.
Et ainsi de suite...... etc....
bon code...

[alex61]

donc en faite une thread c'est un processus ...
c'est ca ?

[Pol63]

mais est-ce que quelqu'un pourrai m'expliquer simplement l'intérêt de thread ?

un exe lancé est un processus
en .net le code s'exécute ligne par ligne sur un thread, par défaut le thread principal, quand on fait du pas à pas on voit bien la ligne d'exécution avancer
pendant l'exécution de code sur le thread principal l'interface graphique est gelée
pour moins d'une demie seconde de traitement ca n'est pas grave (on ne peut juste pas cliquer sur les controles et ils ne se rafraichissent pas), pour moins de 2 dixième de secondes ca ne se voit même pas
au delà c'est génant et on arrive même à "ne répond pas" de windows
pour éviter celà on a recours a l'utilisation d'autres threads
créer un 2ème thread équivaut à avoir une autre ligne d'exécution en pas à pas qui avance à un autre endroit dans le code en même temps que la première

typiquement quand on doit lire des données dans une base de données et que ca va prendre 5 secondes on le fait sur un thread séparé pour laisser libre le thread principal
l'inconvénient c'est que seul le thread principal a le droit de modifier l'interface graphique sinon ca plante "erreur inter thread"


pour faire du multithreading simple, il y a un objet nommé backgroundworker
expliqué ici : http://www.developpez.net/forums/d10...m/#post5757425

le multithreading peut etre dangereux
quand on fait juste du chargement de données et qu'à la fin du thread on repart sur le thread principal pour afficher les données ca ne pose pas de soucis
mais si par exemple tu fais un for each sur une collection et que sur un autre thread tu ajoutes un élément à la collection en même temps, ca plante sur le for each
il y a quand même des choses pour sécuriser le multithreading (synklock, readerwriterlock etc...)

[MABROUKI]

bonjour alex
ce qu'a dit pol est valable à l'interieur d'un processus.
Ce que je voulais dire va plus en profondeur dans l'utilisation des threads par le systeme lui-meme.
Car windows fait du multitache.
Il alloue par defaut un thread principal (petite unite de code) à notre "insu" à chaque processus(application) .
Ensuite il bascule ("switching") constamment d'un processus à l'autre en passant l'execution de code d'un thread 1(application1),à thread2(application2).
ce qui fait schematiquement on a ceci:
appli1->thread principal1(un petit bout de code =A)
appli2->thread principal2(un petit bout de code =B)
appli3->thread principal3(un petit bout de code =C)
Execution Phase 0:
Execute A
Execute B
Execute C
Phase 1:Bascule (suite du code A,de B,de C)
Execute A
Execute B
Execute C
Phase 2:Bascule(idem...)
Execute A
Execute B
Execute C
..............
Phase N: fin ..

Maintenant quand Alex introduit mettons un thread X dans Appli1(A) on a ceci:

Execution Phase 0:
Execute A
Execute X
Execute B
Execute C

Phase 1:Bascule (suite du code A,de B, de C,de X)
Execute A
Execute X
Execute B
Execute C


l'avantage c'est que le code de ta procedure va s'inscruster à toute les phase de la queue d'execution des threads au lieu que par exemple en code normal il doit attendre la phase mettons 100 pour etre gere à l'interieur de A.

si tu veux le system regarde les processus comme des "demandeurs d'execution" et pour cela il leur affecte chacun une portion de temps qui correspond à une portion de code(thread) et ensuite il les sert à tour de role.
quand tu cree un thread tu viens d'inserer dans cette chaine de threads.

En resume c'est un abus de language "commode" de dire qu'une application s'execute en fait windows n'execute reellement que des threads.
Je n'ai pas voulu parler des apartments ("cloison de thread" qui serve à cloisonner les donnees propres à chaque thread et inaccessible aux threads)
bon code ......