Problem
WCF requests for my 2 Workflow Services in different Application Pools are not being processed by their respective worker processes. Instead, both worker processes are processing WCF requests for both Workflow Services. This problem only occurs in "Integrated" Managed Pipeline Mode but not "Classic" Managed Pipeline Mode.
Setup
Description
Let's just say for example, I have Workflow Service A (WFSA) and B (WFSB) running under UserA and UserB respectively. They both are expecting WCF calls via Receive activities in the workflow.
When I start the 2 Application Pools, I can see 2 w3wp.exe worker processes running, one as UserA and the other as UserB. I expect that w3wp.exe worker process for UserA should handle WCF requests for WFSA, and w3wp.exe worker process for UserB should handle WCF requests for WFSB.
However, when I start sending WCF messages to the workflows, I can see through the trace log files that both w3wp.exe processes are handling requests for both Workflow Services.
For example, WCF messages for WFSA are being handle by the w3wp.exe worker processes for UserA AND UserB. So if I send 10 WCF messages to WFSA, 4 would be handled by w3wp.exe for UserA, and 6 would be handled by w3wp.exe for UserB.
When I switch the Application Pool to "Classic" Managed Pipeline Mode, the WCF messages are routed to the respective worker processes, as expected.
Is there some configuration that I'm missing?
Any help is greatly appreciated.
Update
In the project I'm working on, WFSA, WFSB, and another WCF Service Application (WCFApp) communicate with each other in the following configuration:
WFSA <==> WFSB <==> WCFApp
We see problems in the following scenario:
The requested resource has moved to the one of the following locations: http://server/AppFolder/WFSB.xamlx/INotifyWhenDone
I can work around this by setting:
<workflowIdle timeToUnload="00:00:00" />
This means the workflow will get persisted immediately when it goes idle, and messages going to the wrong worker process can be processed because it can find the workflow instance in the persistence database. However, this solution is unacceptable because persistence is VERY SLOW.
There are a couple of hot fixes for AppFabric, one of which seems to be related to the problems you are experiencing. Seek here for the links.