Discussion :

[Kagozuma]

Bonjour tout le monde,

J'ai déjà posté mon problème sur msdn, mais j'ai pensé que je pourrais peut être obtenir de l'aide ici.

Je développe un service .NET 4.0 pour consommer les messages de plusieurs queues distantes MSMQ, cela en transactionnel et en asynchrone. Donc pour cela j'utilise la méthode BeginPeek sur chacune des queues, puis dans la callback j'utilise la méthode Receive dans un TransactionScope qui utilise implicitement MSDTC pour la transaction.

Le problème vient du service Microsoft gérant MSMQ, mqsvc.exe, s'executant sur la machine (win7 ou 2k8r2 sp1) où mon service de consommation s'execute (cette machine ne fait que ça, ni queue ni message ne sont créé dans le MSMQ de cette machine). mqsvc.exe s'alloue de plus en plus de mémoire, lentement, mais sans jamais la libérer, jusqu'à atteindre le maximum de 2Go qu'il peut s'allouer et fini donc par planter totalement. Le seul moyen de libérer cette mémoire est de redémarrer le service.

Toutes les clés de registre concernant les intervalles de vidage du cache pour MSMQ ont des valeurs qui tournent autour de la minute.

J'ai essayé plusieurs choses histoire d'identifier la source de ce problème :

-utiliser MSDTC en local ou en distant, dans le cas du distant, j'utilise évidemment la machine où les messages sont stockés comme machine distante.
-utiliser la librairie COM mqoa.dll à la place de .NET pour l'utilisation de MSMQ, pour pouvoir utiliser explicitement MSDTC avec MSMQ.
-tester cela sur différentes machines (que des win7 ou 2k8r2 sp1)

Mon service s’exécute sans aucune exception et tout ce qui peut être dispose ou close, l'est dès que possible.

Dans tous les cas essayés, ce problème est toujours présent (et j'ai que ce soucis là à chaque fois).

Quelqu'un a une idée pour résoudre ce problème ?

Merci d'avance !

[Bluedeep]

Je vois peut être un scénario pour créer éventuellement ton problème : fermer et disposer correctement tes objets MessageQueue mais en oubliant de désabonner les événements PeekCompleted et/ou PeekReceived préalablement au Dispose.

Test déjà ça (mais sans garantie aucune).

[Kagozuma]

Je le fais déjà, même si normalement le close est sensé le faire. Mais dans tous les cas je fais tous ça seulement dans le cas où une erreur s'est passée lors l'utilisation de l'objet queue, ou que j’arrête mon service. Alors que mqsvc.exe s'alloue de la mémoire durant l’exécution normale du service et que les seules actions sur MSMQ qui pourrait créer cet effet, sont mes Receive dans ma callback et le BeginPeek une fois que le message est fini de traiter. Merci d'avoir porté de l’intérêt à mon soucis.

[Kagozuma]

Bon, j'ai trouvé ! J'ai enlevé l'utilisation de transactions, ça marche ...

Je pense que la consommation à distance de MSMQ en transactionnel, donc avec des transactions gérées par MSDTC et non MSMQ, crée un memory leak dans le service de MSMQ (mqsvc.exe).

J'vais devoir faire du transactionnel avec des transactions maisons ...

J'vais voir comment faire une requête pour un hotfix chez MS.

[Bluedeep]

Bon, j'ai trouvé ! J'ai enlevé l'utilisation de transactions, ça marche ...

Je pense que la consommation à distance de MSMQ en transactionnel, donc avec des transactions gérées par MSDTC et non MSMQ, crée un memory leak dans le service de MSMQ (mqsvc.exe).

C'est curieux ... j'ai déjà eu des archi où les transactions étaient gérées par MSDTC (car le scope transactionnel devait inclure pluseiurs bases de données) et n'ai pas souvenir de ce problème. (il est vrai que je ne me souviens plus si MSMQ était inclus dans le scope transactionnel).

[Kagozuma]

Je trouve ça curieux aussi, mais j'ai pas eu vraiment de réponses a mon soucis peut importe où je l'ai posté. Après la consommation des queues MSMQ à distances n'est pas quelque chose de commun encore moins en transactionnel, surtout que ce n'est disponible que depuis la version 4 je crois, ce n'est ni quelque chose de conseillé, vu l'impact en performance que ça a. Après c'est peut être l'utilisation de ça couplé avec l'asynchrone ? Vu qu'il y'a eu des leaks connus par le passé avec les peek asynchrone.

Mais après tout le temps passé a essayer de résoudre ce soucis et tout ce que j'ai essayé pour continuer a utilisé MSDTC avec MSMQ en remote, je pense pas que c'est mon implémentation qui pose soucis (qui a été maintes fois revue). Au final il faut juste que j'ai l'assurance qu'un message n'est pas supprimé tant que son traitement ne s'est pas déroulé, donc y'a d'autres méthodes moins "propre" que la transaction pour faire ça.

[Kagozuma]

Petit revival du topic pour spécifier que la solution a été trouvé sur MSDN