Nous avons développé une application Winform avec DotNet 2005 en c#.
Lors d'appels asynchrones à des méthodes WebService, l'application se bloque
complètement sur certains postes de nos clients (windows XP Pro SP2) et il
faut la terminer à partir du gestionnaire de tâches. Les appels synchrones
quant à eux fonctionnent sans problème.
Par ailleurs, avec un analyseur de flux, nous avons pu constater que les
échanges avec le serveur sont tout à fait conformes même dans le cas où
l'application cliente se bloque.
Quelqu'un a-t'il déja constaté ce problème et y aurait-il une solution autre
que transformer tous les appels en synchrone ?
Nous avons développé une application Winform avec DotNet 2005 en c#.
Lors d'appels asynchrones à des méthodes WebService, l'application se bloque
complètement sur certains postes de nos clients (windows XP Pro SP2) et il
faut la terminer à partir du gestionnaire de tâches. Les appels synchrones
quant à eux fonctionnent sans problème.
Par ailleurs, avec un analyseur de flux, nous avons pu constater que les
échanges avec le serveur sont tout à fait conformes même dans le cas où
l'application cliente se bloque.
Quelqu'un a-t'il déja constaté ce problème et y aurait-il une solution autre
que transformer tous les appels en synchrone ?
Nous avons développé une application Winform avec DotNet 2005 en c#.
Lors d'appels asynchrones à des méthodes WebService, l'application se bloque
complètement sur certains postes de nos clients (windows XP Pro SP2) et il
faut la terminer à partir du gestionnaire de tâches. Les appels synchrones
quant à eux fonctionnent sans problème.
Par ailleurs, avec un analyseur de flux, nous avons pu constater que les
échanges avec le serveur sont tout à fait conformes même dans le cas où
l'application cliente se bloque.
Quelqu'un a-t'il déja constaté ce problème et y aurait-il une solution autre
que transformer tous les appels en synchrone ?
On Tue, 21 Nov 2006 02:33:02 -0800, Charly28 wrote:
> Nous avons développé une application Winform avec DotNet 2005 en c#.
> Lors d'appels asynchrones à des méthodes WebService, l'application se bloque
> complètement sur certains postes de nos clients (windows XP Pro SP2) et il
> faut la terminer à partir du gestionnaire de tâches. Les appels synchrones
> quant à eux fonctionnent sans problème.
> Par ailleurs, avec un analyseur de flux, nous avons pu constater que les
> échanges avec le serveur sont tout à fait conformes même dans le cas où
> l'application cliente se bloque.
>
> Quelqu'un a-t'il déja constaté ce problème et y aurait-il une solution autre
> que transformer tous les appels en synchrone ?
Ce genre de probleme avec des appels asynchrones est la plupart du temps du
au fait que la méthode callback, appelée lorsque l'appel est terminé et
exécutée dans un thread du threadpool, tente d'accéder a des Controls
(buttons, fenetres, text box...) sans auparavant marshaller l'appel dans le
thread de l'UI.
Accéder a des controles de l'interface graphique sous Windows depuis un
autre thread que le thread de l'UI n'est pas supporté. Tenter de le faire
parfois semble fonctionner, parfois crash l'application d'une maniere
totalement imprévisible. Je commencerai par analyser le code afin de voir
s'il n'y aurai pas un bout de code quelque part qui accede a l'interface
graphique alors qu'il n'est pas exéctuté dans le thread de l'UI.
Si ce n'est pas la cause du probleme, alors il doit y avoir un deadlock
quelque part.
On Tue, 21 Nov 2006 02:33:02 -0800, Charly28 wrote:
> Nous avons développé une application Winform avec DotNet 2005 en c#.
> Lors d'appels asynchrones à des méthodes WebService, l'application se bloque
> complètement sur certains postes de nos clients (windows XP Pro SP2) et il
> faut la terminer à partir du gestionnaire de tâches. Les appels synchrones
> quant à eux fonctionnent sans problème.
> Par ailleurs, avec un analyseur de flux, nous avons pu constater que les
> échanges avec le serveur sont tout à fait conformes même dans le cas où
> l'application cliente se bloque.
>
> Quelqu'un a-t'il déja constaté ce problème et y aurait-il une solution autre
> que transformer tous les appels en synchrone ?
Ce genre de probleme avec des appels asynchrones est la plupart du temps du
au fait que la méthode callback, appelée lorsque l'appel est terminé et
exécutée dans un thread du threadpool, tente d'accéder a des Controls
(buttons, fenetres, text box...) sans auparavant marshaller l'appel dans le
thread de l'UI.
Accéder a des controles de l'interface graphique sous Windows depuis un
autre thread que le thread de l'UI n'est pas supporté. Tenter de le faire
parfois semble fonctionner, parfois crash l'application d'une maniere
totalement imprévisible. Je commencerai par analyser le code afin de voir
s'il n'y aurai pas un bout de code quelque part qui accede a l'interface
graphique alors qu'il n'est pas exéctuté dans le thread de l'UI.
Si ce n'est pas la cause du probleme, alors il doit y avoir un deadlock
quelque part.
On Tue, 21 Nov 2006 02:33:02 -0800, Charly28 wrote:
> Nous avons développé une application Winform avec DotNet 2005 en c#.
> Lors d'appels asynchrones à des méthodes WebService, l'application se bloque
> complètement sur certains postes de nos clients (windows XP Pro SP2) et il
> faut la terminer à partir du gestionnaire de tâches. Les appels synchrones
> quant à eux fonctionnent sans problème.
> Par ailleurs, avec un analyseur de flux, nous avons pu constater que les
> échanges avec le serveur sont tout à fait conformes même dans le cas où
> l'application cliente se bloque.
>
> Quelqu'un a-t'il déja constaté ce problème et y aurait-il une solution autre
> que transformer tous les appels en synchrone ?
Ce genre de probleme avec des appels asynchrones est la plupart du temps du
au fait que la méthode callback, appelée lorsque l'appel est terminé et
exécutée dans un thread du threadpool, tente d'accéder a des Controls
(buttons, fenetres, text box...) sans auparavant marshaller l'appel dans le
thread de l'UI.
Accéder a des controles de l'interface graphique sous Windows depuis un
autre thread que le thread de l'UI n'est pas supporté. Tenter de le faire
parfois semble fonctionner, parfois crash l'application d'une maniere
totalement imprévisible. Je commencerai par analyser le code afin de voir
s'il n'y aurai pas un bout de code quelque part qui accede a l'interface
graphique alors qu'il n'est pas exéctuté dans le thread de l'UI.
Si ce n'est pas la cause du probleme, alors il doit y avoir un deadlock
quelque part.
Après vérification du code, il n'y a aucun accès à des controles dans la
méthode de callback.
Le problème viendrai plutôt de la configuration des postes où il y a
blocage, car sur les postes où ces appels fonctionnent, je n'ai jamais eu
aucun blocage.
La question serait donc : qu'est ce qui, dans la configuration d'un poste,
pourrait bloquer les appels asynchrones à un webservice ?
Après vérification du code, il n'y a aucun accès à des controles dans la
méthode de callback.
Le problème viendrai plutôt de la configuration des postes où il y a
blocage, car sur les postes où ces appels fonctionnent, je n'ai jamais eu
aucun blocage.
La question serait donc : qu'est ce qui, dans la configuration d'un poste,
pourrait bloquer les appels asynchrones à un webservice ?
Après vérification du code, il n'y a aucun accès à des controles dans la
méthode de callback.
Le problème viendrai plutôt de la configuration des postes où il y a
blocage, car sur les postes où ces appels fonctionnent, je n'ai jamais eu
aucun blocage.
La question serait donc : qu'est ce qui, dans la configuration d'un poste,
pourrait bloquer les appels asynchrones à un webservice ?
On Tue, 21 Nov 2006 10:14:02 -0800, Charly28 wrote:
> Après vérification du code, il n'y a aucun accès à des controles dans la
> méthode de callback.
Sur et certain ? Les méthode callback ne leveraient pas un évenement qui en
leverait un autre qui finalement tenterai d'accéder a une fenetre ou une
listbox ?
On Tue, 21 Nov 2006 10:14:02 -0800, Charly28 wrote:
> Après vérification du code, il n'y a aucun accès à des controles dans la
> méthode de callback.
Sur et certain ? Les méthode callback ne leveraient pas un évenement qui en
leverait un autre qui finalement tenterai d'accéder a une fenetre ou une
listbox ?
On Tue, 21 Nov 2006 10:14:02 -0800, Charly28 wrote:
> Après vérification du code, il n'y a aucun accès à des controles dans la
> méthode de callback.
Sur et certain ? Les méthode callback ne leveraient pas un évenement qui en
leverait un autre qui finalement tenterai d'accéder a une fenetre ou une
listbox ?
"Mehdi" a écrit :On Tue, 21 Nov 2006 10:14:02 -0800, Charly28 wrote:
> Après vérification du code, il n'y a aucun accès à des controles dans
> la
> méthode de callback.
Sur et certain ? Les méthode callback ne leveraient pas un évenement qui
en
leverait un autre qui finalement tenterai d'accéder a une fenetre ou une
listbox ?
A tout hasard, ci-dessous le code de la méthode callback :
void wsService_TestCompleted(object sender, TestCompletedEventArgs
e)
{
try
{
xeMessageRetour = e.Result.Description;
}
catch
{
CodeErreur = "-002";
MessageErreur =
Traduction.ServiceMessagerie_ErreurConnection;
}
((AsyncStatut)e.UserState).Termine = true;
}
xeMesssageRetour est un XmlElement déclaré au niveau de la classe.
CodeErreur et Message Erreur sont de type String déclaré également au
niveau
de la classe.
AsyncStatut défini uniquement une propriété de type Booleen (Termine) et
ne
déclenche aucun évènement. Cette propriété sert juste à autoriser la
sortie
d'une boucle d'attente juste après l'appel asynchrone.
Donc autant que je puisse juger, il n'y a rien qui corresponde au cas de
figure que tu m'as décrit.
Ne pouvant résoudre le problème j'ai donc décidé de le contourner en
autorisant à, défaut de mieux, le choix entre appels synchrone et
asynchrone
; tant pis pour le rafraichissement de l'interface utilisateur pendant les
appels WS.
En tous cas , un grand merci pour le temps que tu as consacré à mon
problème. Et puis j'aurais appris qu'il ne faut pas manipuler des objets
de
l'UI dans une méthode callback. Ca m'évitera de perdre du temps une autre
fois.
"Mehdi" a écrit :
On Tue, 21 Nov 2006 10:14:02 -0800, Charly28 wrote:
> Après vérification du code, il n'y a aucun accès à des controles dans
> la
> méthode de callback.
Sur et certain ? Les méthode callback ne leveraient pas un évenement qui
en
leverait un autre qui finalement tenterai d'accéder a une fenetre ou une
listbox ?
A tout hasard, ci-dessous le code de la méthode callback :
void wsService_TestCompleted(object sender, TestCompletedEventArgs
e)
{
try
{
xeMessageRetour = e.Result.Description;
}
catch
{
CodeErreur = "-002";
MessageErreur =
Traduction.ServiceMessagerie_ErreurConnection;
}
((AsyncStatut)e.UserState).Termine = true;
}
xeMesssageRetour est un XmlElement déclaré au niveau de la classe.
CodeErreur et Message Erreur sont de type String déclaré également au
niveau
de la classe.
AsyncStatut défini uniquement une propriété de type Booleen (Termine) et
ne
déclenche aucun évènement. Cette propriété sert juste à autoriser la
sortie
d'une boucle d'attente juste après l'appel asynchrone.
Donc autant que je puisse juger, il n'y a rien qui corresponde au cas de
figure que tu m'as décrit.
Ne pouvant résoudre le problème j'ai donc décidé de le contourner en
autorisant à, défaut de mieux, le choix entre appels synchrone et
asynchrone
; tant pis pour le rafraichissement de l'interface utilisateur pendant les
appels WS.
En tous cas , un grand merci pour le temps que tu as consacré à mon
problème. Et puis j'aurais appris qu'il ne faut pas manipuler des objets
de
l'UI dans une méthode callback. Ca m'évitera de perdre du temps une autre
fois.
"Mehdi" a écrit :On Tue, 21 Nov 2006 10:14:02 -0800, Charly28 wrote:
> Après vérification du code, il n'y a aucun accès à des controles dans
> la
> méthode de callback.
Sur et certain ? Les méthode callback ne leveraient pas un évenement qui
en
leverait un autre qui finalement tenterai d'accéder a une fenetre ou une
listbox ?
A tout hasard, ci-dessous le code de la méthode callback :
void wsService_TestCompleted(object sender, TestCompletedEventArgs
e)
{
try
{
xeMessageRetour = e.Result.Description;
}
catch
{
CodeErreur = "-002";
MessageErreur =
Traduction.ServiceMessagerie_ErreurConnection;
}
((AsyncStatut)e.UserState).Termine = true;
}
xeMesssageRetour est un XmlElement déclaré au niveau de la classe.
CodeErreur et Message Erreur sont de type String déclaré également au
niveau
de la classe.
AsyncStatut défini uniquement une propriété de type Booleen (Termine) et
ne
déclenche aucun évènement. Cette propriété sert juste à autoriser la
sortie
d'une boucle d'attente juste après l'appel asynchrone.
Donc autant que je puisse juger, il n'y a rien qui corresponde au cas de
figure que tu m'as décrit.
Ne pouvant résoudre le problème j'ai donc décidé de le contourner en
autorisant à, défaut de mieux, le choix entre appels synchrone et
asynchrone
; tant pis pour le rafraichissement de l'interface utilisateur pendant les
appels WS.
En tous cas , un grand merci pour le temps que tu as consacré à mon
problème. Et puis j'aurais appris qu'il ne faut pas manipuler des objets
de
l'UI dans une méthode callback. Ca m'évitera de perdre du temps une autre
fois.
