Le flux de travail hébergé AppFabric ne se recharge pas toujours après un délai/un déchargement

Question

J'ai un service de workflow WCF Windows Workflow (4.5) hébergé sous IIS et utilisant AppFabric 1.1. Les instances de workflow sont de longue durée (jusqu'à environ une semaine), mais une grande partie du temps est consacré aux activités de retard. Cela a semblé fonctionner correctement au début, mais lors de l'exécution de plusieurs instances du workflow en même temps (2+ instances le provoquent), certaines d'entre elles ne se réveillent jamais une fois qu'elles ont été déchargées de la mémoire pendant l'étape Delay. . Quand je regarde les journaux, les erreurs que je trouve tout ressemblent à ceci:

   System.OperationCanceledException: The execution of InstancePersistenceCommands has been canceled because the InstanceHandle was freed. 
      at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) 
      at System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.WaitAndHandleStoreEventsCallback(IAsyncResult result) 

Malheureusement, je ne trouve aucune information utile sur ce message d'erreur.

Les champs SuspensionExceptionName et SuspensionReason dans la table InstFabric Persisted Instances montrent System.NullReferenceException: référence d'objet non définie sur une instance d'un objet. Mais cela n'arrive pas dans mon flux de travail, seulement à l'extérieur.

Informations additionnelles:

• Je me présente l'activité comme un feu & Oublie (activité de réception, pas d'envoi)
• Mon flux de travail appelle à d'autres services WCF pour récupérer les données.
• Je cours ceci sur le serveur 2012 R2, IIS 8 (pas azur)
• La persistance de workflow fonctionne. Je peux réinitialiser IIS, redémarrer ... c'est juste quand je cours 2 instances qu'il a des problèmes. Je ne suis absolument pas en train de limiter les limitations. Alors que le workflow traite de quelques Mo de données, ce problème se produit sur 2+ instances.

Une idée de ce qui pourrait se passer ici?

Editer: J'ai réalisé que j'avais trouvé plus d'informations sur le fonctionnement du problème et je ne l'ai jamais ajouté à la question. Lorsque le problème de délai se produit, il fonctionne beaucoup comme une variable statique écrite par 2 threads.

Voici une visualisation:

WF1 Start ---->Do Stuff--->Sleep------------*1----->Cancelled Exception at some point 

------WF 2 Start---->Do Stuff------->Sleep->Wake up---------*2------>More Stuff---->End Successfully 

*1 - When WF Instance 1 Should Wake up (Same time as WF 2 wakes) 

*2 - When WF Instance 2 Should have woken up (Seems to be ignored) 

Avant que quelqu'un ne demande ... je me suis débarrassé de chaque variable statique, méthode, classe dans mon code. Rien n'est plus statique.

Answer 1

J'ai lutté avec des problèmes similaires pendant un certain temps. J'utilise WFW4 et je trouve des erreurs similaires lorsqu'une instance de workflow est dans un long délai.

Je ne sais pas quelle est la cause du problème, mais j'ai un travail que vous pourriez trouver utile. Dans mon cas, les erreurs que je reçois proviennent de Workflow Management Service et disent: Échec de l'appel du point de terminaison de la gestion des services à 'net.pipe: //.svc' pour activer le service '/Alerts/Workflows/.xamlx' . Exception: "Accès refusé".

Ces erreurs commencent à se produire entre 6 et 30 heures après que l'instance a été retardée.

J'ai découvert que si je crée une nouvelle instance du workflow lorsque la première instance est en attente et que les erreurs se produisent, le service de gestion de workflow peut reprendre l'interaction avec la première instance en veille. Donc, j'ai fait un nouveau workflow dont le seul but est de lancer périodiquement puis de tuer les instances du workflow qui contient le long délai.

Il devient un peu plus compliqué de faire ce travail. Je voulais que ce nouveau flux de travail s'endorme entre les moments où il crée et tue une nouvelle instance du premier flux de travail. Mais cette mise en veille provoque l'occurrence du nouveau flux de travail dans le même problème que le premier flux de travail. Donc, j'ai modifié le nouveau flux de travail de sorte qu'il fait ce qui suit: - retarder pour une période plutôt courte, comme 30 minutes - créer une instance du premier flux de travail - attendez une minute - tuer le just- instance créée du premier flux de travail - créer une nouvelle instance de cette nouvelle erreur empêchant flux - mettre fin à

depuis avoir fait cela, je ne reçois plus l'accès est refusé erreur de workflow service de gestion!

Hope this helps

Answer 2

Transforme ma première réponse n'a pas été correcte, mais je crois que cette réponse est juste, et résout le problème ChrisG est d'avoir.

Ma solution de contournement n'a pas fonctionné réellement. Il a fallu un moment pour que le problème refasse surface. 29 heures pour être précis - le temps par défaut qu'il faut pour recycler un pool d'applications.

Donc pour moi, la solution était de faire en sorte que mon pool d'applications ne soit pas recyclé. Lorsqu'un pool d'applications est recyclé alors qu'une instance de workflow est dans une activité de délai, le workflowManagementService ne peut pas réactiver l'instance et déclenche des erreurs Access is Denied. Si vous créez une nouvelle instance du flux de travail après le recyclage du pool d'applications, la première instance reprendra là où elle s'était arrêtée, mais elle a parfois encore des problèmes, ce qui est le cas pour ChrisG.

ChrisG, en regardant votre visualisation, est-il possible qu'un appPool soit recyclé pendant le temps de sommeil de wf1? Je crois que c'est la cause de l'exception. Si vous lancez ensuite une nouvelle instance wf après que * 2 soit passé (et si un recycle de pool d'applications est arrivé avant * 1), cela réveillera à la fois wf1 et wf2, mais wf1 ne fonctionnera pas correctement (du moins selon mon expérience)

De plus, cela se produit après le redémarrage du serveur iisreset. Pour les gérer, vous devez utiliser IIS7, ce qui permet à l'application Web (ainsi qu'au site Web) qui héberge les fichiers xamlx de se lancer automatiquement après le redémarrage d'un iisreset ou d'un serveur. Cette option n'est pas disponible dans IIS6. Voir http://www.postseek.com/meta/991815402b369e71ce925cde47ac907d pour les détails

Espérons que cela aide!