After battling with a Custom Tracking Service that stopped running after having to change the Assembly Sig, which is outlined here: http://social.msdn.microsoft.com/Forums/en-US/windowsworkflowfoundation/thread/fd0b3e38-d839-4f5b-bbb5-6bce5f3ed1bb
I am getting the following error when rehydrating the previously serialised workflows with the Custom Tracking Service fix that is the solution to the original post.
It's important to note that this only happens after the first workflow of the sepcific type is successfully rehydrated, and a second workflow using the same Workflow Type is rehydrated.
So to be clear, I can rehydrate WF1 of TypeA, then WF2 of TypeB, but if I try and rehydrate WF3 of TypeA, I get the following error (this only happens with version 18.104.22.168 of the workflows, any newly created workflow with version 22.214.171.124 have no hitch with the tracking profiles):
It's as though the system is now recognising the tracking service, retrieving it, adding it to the cache but when another workflow with the same type is loaded it checks the cache and it doesn't find a match, so it tries to retrieve the tracking profile and insert into the cache, but then gets an error because it's already in the cache (so the sig for checking that the cache is different from the sig used to insert into the cache?).
Any help would be appreciated.
The problem is, we _haven't_ deployed any new versions - this started happening spontaneously on a client's production machine.
I'm wondering if an IT windows patch changed something, but I haven't been able to verify that anything was patched at all.
I did look at the PreviousTrackingService attribute, but we don't have any previous versions (having not actually upgraded anything). Plus, the exception is the same as yours - System.ApplicationException: Profile cache insert failure - not the System.Workflow.Runtime.QueueException from the KB article
Thanks for your suggestions, though!2012年12月14日 14:45
Hmm, now we're working on a new theory - we have a relatively new DEV site that happens to also be deployed to the same server, different App Pools.
We haven't changed the workflow component version numbers, but some internal code in the workflows may have changed, leading to two different tracking services in two different assemblies, in two different IIS applications.
What happens is our PROD will run a workflow fine the first time after an app pool restart, but the second time returns the: System.ApplicationException: Profile cache insert failure.
We're working on a theory that the secondary application with matching workflow version number is somehow causing an issue, even though it is in a separate app pool.
Stay tuned.2012年12月14日 15:21
Even more strangeness.
We have 2 workflows ("draft document", "review document"), 1 tracking service, same version numbers between DEV and PROD, on the same server.
Shutting down the DEV app pool entirely seems to have made the "draft document" workflow behave correctly. We can run through the workflow multiple times, no errors. (previously we could only run it once before the "profile cache insert failure" message)
HOWEVER, the "review document" workflow, if we run that one, it's now exhibiting the same issues as the "draft document" workflow was - you can run it once, but the 2nd time you get the "profile cache insert failure" exception). This is with the DEV app pool shut down.
What does this mean!? My hunch that the dev app pool was somehow interfering with matching version numbers seems to be invalid, now, since even though it "fixed" the draft workflow, it doesn't seem to have fixed the review workflow.
Also, on your suggestion about that KB article - these servers are 2008 x64 servers, and when I attempted to get the hotfix, I was curtly informed that it only applied to XP and 2003 Server, and they wouldn't give it to me. (Maybe it's already rolled in?)
- 已编辑 andrewrarace 2012年12月17日 16:15 additional information