2009-09-18 14 views
2

J'ai un processus dotnet qui, via des appels à une DLL non gérée, communique avec un processus Java.Est-ce probable que les domaines d'application aideront dans ce scénario?

Dans certaines circonstances, le processus Java semble se bloquer et entraîner mon processus dotnet avec lui. Aucune exception n'est soulevée, le processus meurt juste. Lors de l'écrasement, java crée un fichier journal avec des noms comme "hs_err_pid3228" etc.

N'ayant reçu aucune satisfaction du fournisseur qui fournit la DLL non managée et le processus Java, je suis réduit à essayer d'atténuer le problème nécessiterait d'assurer les appels dans le processus Java, s'ils tombent en panne, ne pas arrêter mon processus. Après avoir lu divers articles, appdomains semblent un candidat probable à utiliser - ma théorie étant que je peux avec un peu de travail séparer mes fonctionnalités qui appelle le processus Java et l'exécuter dans un domaine distinct, ce qui, je l'espère, me permettra si pas attraper l'appdomain en descendant, au moins détecter que cela s'est produit et redémarrer cette fonctionnalité.

Quelqu'un a-t-il eu un problème similaire? Cette approche semble-t-elle raisonnable à ceux d'entre vous qui ont plus d'expérience de l'appdomain?

Pour le rendre encore plus amusant, le crash Java est pas vraiment reproductible - il semble très aléatoire et je suis toujours aux prises avec la façon dont je vais test qui sépare dans le appdomain

Répondre

1

C'est raisonnable l'utilisation de AppDomains, et ce que vous proposez fonctionnera. Dans le même ordre d'idées, j'ai déjà utilisé AppDomains pour créer une seule application qui se surveillait en se plantant à des fins de génération de rapports d'exception. L'application a démarré elle-même, a créé un nouveau AppDomain, puis s'est exécutée de nouveau dans le nouveau AppDomain, qui a alors détecté qu'elle était en cours d'exécution dans un AppDomain et exécutée normalement. Lorsqu'une exception s'est produite dans ce domaine, le processus d'origine est notifié, il démonte les rapports de domaine enfant à l'utilisateur qu'une erreur est survenue, demande s'ils souhaitent le signaler ou non, puis se reprend et l'essaie à nouveau.

EDIT: Pour vous donner un bon départ, si vous voulez regarder les Program.cs pour ce projet, je ai téléchargé une version dépouillée ici . (Il est assez long, donc je ne pensais pas que je devrais le poster ici.)

+0

Merci - c'est rassurant que cela vaut la peine d'essayer. Maintenant, je dois juste convaincre la direction de m'attribuer le temps de rassembler au moins une preuve de concept. – user50380

0

Oui, tirer parti de AppDomains a beaucoup de sens ici.

J'ai récemment retravaillé mon service Windows pour charger ses divers services WCF en tant que plug-ins fonctionnant dans leur propre AppDomain. J'ai quelques cas dans le processus d'amorçage où j'utilise des objets MarshalByRefObject pour mettre les choses en marche, mais une fois que les plug-ins sont chargés, la communication entre les AppDomains est extrêmement facile en utilisant WCF.