locked
Instance store and correlation keys RRS feed

  • Question

  • I just discovered that the keys saved in the InstanceStore (SQLServer) is generated not only with the given correlation key, but it also uses the web-server name to calculate the final key.

    This means that you can not make a backup of the instance store and restore it somewhere else.
    You cannot have fail-over application server etc.

    Does anyone know how to avoid this problem?

    Thanks

    You will get messages like this if you try:
    The execution of an InstancePersistenceCommand was interrupted because the instance key 'b7a2a224-dea6-8a00-7671-5c6ce0af4fbe' was not associated to an instance. This can occur because the instance or key has been cleaned up, or because the key is invalid. The key may be invalid if the message it was generated from was sent at the wrong time or contained incorrect correlation data.


    Ragnar

    Friday, January 18, 2013 1:48 PM

Answers

  • However there is a workaround, try this debug your workflow service from visual studio but hosted in the iis make sure the website or the virtual directory is the same that your server.

    • Marked as answer by Molly Chen_ Tuesday, February 5, 2013 2:43 AM
    Wednesday, January 30, 2013 12:52 AM

All replies

  • Hi,
    This exception which is thrown out indicates that the InstanceStore couldn't find a workflow associated with that key.
    In order to find the main issue, you need to use Workflow Tracking to track the data on the WorkflowService. For details about how to do it, please check: Troubleshooting Workflow Services with diagnostic logging.

    In addition, you can try to use your own generated GUID instead of using the workflow instance ID as the correlation content. For details about how to do a WF4 correlation sample, please check http://xhinker.com/post/WF4Correlate-Multiple-Receive-Activities.aspx

    You can also follow the similar threads below:

    http://social.msdn.microsoft.com/Forums/en-US/wfprerelease/thread/9c4246cd-5cd6-42f6-bf22-a8830a04e2f2

    http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/1a520c2a-d14b-4785-86cf-94e2f476b4db

    Best wishes,


    Catherine
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 21, 2013 9:29 AM
  • Thank you very much for your response!
    I am using my own GUID as the correlation key (sm:body()/xg0:ValidateWorkflowRequest/xg0:WorkflowInstanceId).

    WorkflowInstanceId is not the same as InstanceStore id.

    Evrything is working well from one application server, the problem is if I am switching to another server and try to load the same instance. I have traced a lot, and found that the key used in System.Activities.DurableInstancing.KeysTable changes based on the application server's name.

    I think this article is addressing the same problem:Correlation keys

    I would be happy if there is a workaround to this problem, as we have a production environment with backup app servers.

    Best regards


    Ragnar

    Monday, January 21, 2013 10:07 AM
  • I have been digging a litte bit more, and I think the answer lies in the table ServiceDeploymentsTable. It contains one row for each combination of xamlx path, site name etc. and is probably used in combination with the Correlation key (a guid that I know is globally unique).

     Here is an example from my deployment table:

    Id ServiceDeploymentHash SiteName RelativeServicePath RelativeApplicationPath ServiceName ServiceNamespace
    1012 895B8ACB-A9CB-4E19-17F1-AAB2B22DC4FD Default Web Site /wats-wf/xaml/14bed9bc-9633-47d8-9593-d1401969b679.xamlx /wats-wf _x0031_4bed9bc-9633-47d8-9593-d1401969b679.xamlx /Default Web Site/wats-wf/xaml/
    1068 EE022B1F-6F50-C023-1729-B2B8B40A8B44 Default Web Site /wats-wf/xaml/07a32184-be6a-4c37-b2a9-c66245cb2b85.xamlx /wats-wf _x0030_7a32184-be6a-4c37-b2a9-c66245cb2b85.xamlx /Default Web Site/wats-wf/xaml/
    1668 88B0D554-E95B-B1EE-B2F9-5F3B8621E42E Default Web Site /VEMY/wats-wf/xaml/14bed9bc-9633-47d8-9593-d1401969b679.xamlx /VEMY/wats-wf _x0031_4bed9bc-9633-47d8-9593-d1401969b679.xamlx /Default Web Site/VEMY/wats-wf/xaml/
    1669 8E9F9ACC-8C16-0368-6B83-CF99B2CC3EB7 Default Web Site /VEMY/wats-wf/xaml/4e1e1c34-11a0-42db-b994-b641add7f770.xamlx /VEMY/wats-wf _x0034_e1e1c34-11a0-42db-b994-b641add7f770.xamlx /Default Web Site/VEMY/wats-wf/xaml/


    Ragnar


    Monday, January 21, 2013 1:33 PM
  • PS: I am still interested in switching off this behaviour, we have our own service versioning mechanism.


    Ragnar


    Monday, January 21, 2013 1:37 PM
  • Hello from Colombia

    I'm facing the same problem, but I did it in another project I mean, I was able to start instances in one server and they make a database backup restore it locally and continue excecuting those instances.

    But in this new project I'm not able to do it again.......the same calculated correlation key issue is happening to me........

    If I solve the problem I'll share the solution with you........however if you find the solution please share if

    Wednesday, January 30, 2013 12:07 AM
  • However there is a workaround, try this debug your workflow service from visual studio but hosted in the iis make sure the website or the virtual directory is the same that your server.

    • Marked as answer by Molly Chen_ Tuesday, February 5, 2013 2:43 AM
    Wednesday, January 30, 2013 12:52 AM
  • Any luck on this guys? I am having the same problem when moving my persistence store to a new  environment.

    I can start new workflows however I cannot resume persisted workflows, returns the same error "The execution of an InstancePersistenceCommand was interrupted because the instance key '{GUID}' was not associated to an instance. This can occur because the instance or key has been cleaned up, or because the key is invalid.[...]"

    My website name is exactly the same, including case, however I have a different server name. I notice that the URI is used in some calls leading up to the failure. Can someone PLEASE shed some light on exactly what environment-specific variables are used in creating the instance key besides what I correlate on. I would really love to avoid cracking open reflector on this one...

    I have seen some posts saying that it uses the web site name and this one suggesting it also uses the web server name. My workflows work faultlessly in their existing environment, as do new ones created in the new environment.

    Wednesday, June 19, 2013 1:46 PM