Home → Support →

Error when trying to use persistent WF4 workflows

• Edit

Vagif Abilov

13 Feb, 2011 09:56 AM

I have made a few simple WF4 workflows to test how workflow foundation functionality works on AppHarbor (planning to write an article with guidelines). The worklows are hosted in a REST Web service. If I use non-persistent workflows, then everything works fine, so we can say that AppHarbor can be used to host WF workflows. But the most interesting scenario is to use persistent workflows that gets dehydrated when long-running worklows are not active. In order to implement them I added a database to my respository and populated it with WF db schemas and stored procedures that are required to implement persistence. I can connect to a database using SQL Server Management Studio and check that the tables and SPs are in place. But when I try to start a persistent workflow, I receive an error with very little information: "The server encountered an error processing the request. Please see the service help page for constructing valid requests to the service."
BTW, this error leads to another question: what is a best way to implement diagnostics on AppHarbor? I tried to search for some recommendations, but didn't find anything.

Thanks in advance.

1. 1 Posted by Vagif Abilov on 13 Feb, 2011 01:25 PM

   

   I've added exception handler to the failing operation that returns an error message, and here is what I get:
   "The execution of the InstancePersistenceCommand named {urn:schemas-microsoft-com:System.Activities.Persistence/command}CreateWorkflowOwner was interrupted by an error."

   To reproduce it, goto http://workflows.apphb.com/paccumulate

   • Edit

2. Support Staff 2 Posted by friism on 13 Feb, 2011 07:20 PM

   

   There's some information on that error here. It would to interesting to have a look at the rest of the stacktrace. If you invite [email blocked] as a collaborator on the application, I'd be happy to take a closer look.

   • Edit

3. 3 Posted by Vagif Abilov on 13 Feb, 2011 08:52 PM

   

   Hi Michael,

   I've added support as a contributor. I also found that thread, but I don't think it it relevant. That discussion was more about changes in persistence store implementation in WF4. I've rewritten code to become more testable and added unit tests that for some reasons I am unable to run (I've posted another topic about it).

   • Edit

4. 4 Posted by Vagif Abilov on 13 Feb, 2011 09:51 PM

   

   Now that I manage to run unit tests, I see that they fail in a trivial step: opening SQL connection. Am I doing this right? I have a connection string called "InstanceStore" defined for the database. And this is what I use in web.config (and app.config for unit tests). I suppose the actual content is replaced with the one defined for my application, so I wonder why connection.Open fails.

   • Edit

5. 5 Posted by Vagif Abilov on 13 Feb, 2011 10:09 PM

   

   Hm, and if I paste appharbor connection string into my local app.config, then tests run fine locally, e.g. I can successfully use AppHarbor database to execute tests on my local machine. But they fail when being executed on AppHarbor server.

   • Edit

6. Support Staff 6 Posted by friism on 13 Feb, 2011 10:47 PM

   

   We don't replace your connectionstring before running your unit tests (it's replaced after unit tests complete succesfully). Using your AppHarbor database when running unit tests is probably a really bad idea since your unit tests might clean tables or insert random rows that are not removed. For unit tests, we recommend using an in-memory db (we use SQLite). Your database-code can figure out if it's being unit tested (and decide on what database to use) by looking at the Environment app setting.

   I'm looking at your app now to figure out what's going on.

   • Edit

7. Support Staff 7 Posted by friism on 14 Feb, 2011 01:18 AM

   

   If I comment out your unit tests and try your code now, it seems to work (http://support-test-workflow.apphb.com/paccumulate). Note that I had to hardcode the connectionstring because I'm testing in a different app from yours. The connectionstring replacement should work fine for your app though.

   Let me know if you're still experiencing problems.

   P.S.: You asked about error-loggin. It's something we would like to handle better, but in the mean-time, I've put up an example in the knowledge base.

   • Edit

8. friism closed this discussion on 14 Feb, 2011 01:18 AM.

9. Vagif Abilov re-opened this discussion on 14 Feb, 2011 07:14 AM

10. 8 Posted by Vagif Abilov on 14 Feb, 2011 07:14 AM

    

    Hi Michael,

    It does not look like I can use SQLite for testing WF projects, because
    AFAIK WF uses SqlConnection and MS-SQL schema, that I can not control, at
    least not without serious changes. So in case my test are based on MS-SQL
    database, what it the recommended approach for running tests? Create a new
    MS-SQL database just for testing? Looks like overkill.

    Vagif

    On Sun, Feb 13, 2011 at 11:48 PM, Michael Friis <
    [email blocked]> wrote:

    • Edit

11. Support Staff 9 Posted by friism on 14 Feb, 2011 07:53 AM

    

    Hm, I haven't tested this, but you could probably use SQL Server Compact Edition for your unit tests and have it create a database-file on the fly. I'm going to try and figure out where that db-file should be written, expect a mockup tomorrow. Here's a related blog post.

    • Edit

12. 10 Posted by Vagif Abilov on 14 Feb, 2011 11:08 AM

    

    Hi,

    Thanks for the tip. That's interesting. Will try it out.

    Vagif

    On Mon, Feb 14, 2011 at 8:53 AM, Michael Friis <
    [email blocked]> wrote:

    • Edit

13. 11 Posted by Vagif Abilov on 14 Feb, 2011 11:10 AM

    

    And as you said, the crucial thing for me is where db file should be
    written. I need to place in test fixture setup code like this:

    File.Copy("Template.sdf", "Temp.sdf", true);

    What directory can I write it to?

    On Mon, Feb 14, 2011 at 8:53 AM, Michael Friis <
    [email blocked]> wrote:

    • Edit

14. Support Staff 12 Posted by friism on 15 Feb, 2011 07:27 PM

    

    I now have a running example with SQL Server CE unit tests. If you just place the database file in the directory where the unit tests run, you're golden.

    Here's a relevant excerpt:
    

    var databaseFilename = "database.sdf";
    var cconnectionString = string.Format("DataSource=\"{0}\";", databaseFilename);
    
    var sqlCeEngine = new SqlCeEngine(connectionString);
    sqlCeEngine.CreateDatabase();
    

    I then encountered loads of other problems with pushing the SQL Server CE dlls along with the test project. I'll post a sample project shortly.

    • Edit

15. Support Staff 13 Posted by friism on 15 Feb, 2011 08:12 PM

    

    Here's the sample solution with SQL Server CE unit tests that run on AppHarbor.

    Really looking forward to seeing your Workflow demo and let me know if there's anything else I can do to help.

    • Edit

16. friism closed this discussion on 15 Feb, 2011 08:12 PM.

17. Vagif Abilov re-opened this discussion on 15 Feb, 2011 08:47 PM

18. 14 Posted by Vagif Abilov on 15 Feb, 2011 08:47 PM

    

    Great, thanks a lot!

    Will try to test it right away.

    Vagif

    On Tue, Feb 15, 2011 at 9:12 PM, Michael Friis <
    [email blocked]> wrote:

    • Edit

19. 15 Posted by Vagif Abilov on 15 Feb, 2011 10:38 PM

    

    This comment was split into a new private discussion: "Memory gates checking failed"

    Hi Michael,

    While SQL Server CE seems to be a way to go when developers control db schema, it does not work out of the box with Workflow Foundation. The problem is that WF comes with its own schema - not complicated, only one table for durable instances plus some stored procedures. But the schema contains types unsupported on CE (e.g. "xml") and requires some rework.
    I posted a question about it at WF4 forum. In the meantime I disabled my tests in order to bypass testing stage and try the application. Suddenly I received a new error, apparently not related to workflows at all:

    "Memory gates checking failed because the free memory (94674944 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element."

    Looks like the system is low on memory, isn't it?

    • Edit

20. Support Staff 16 Posted by friism on 15 Feb, 2011 10:47 PM

    

    Orgh, too bad about SQL Server CE. Let me know if you come up with a solution.

    • Edit

21. friism closed this discussion on 15 Feb, 2011 10:47 PM.

22. Vagif Abilov re-opened this discussion on 15 Feb, 2011 10:50 PM

23. 17 Posted by Vagif Abilov on 15 Feb, 2011 10:50 PM

    

    Hi again,

    I managed to run persistent workflows! Thanks for your help. I will write a blog post about it shortly, but the conclusion is simple and great: it just works!

    Having said that, I had to disable tests because the only way to persist in a test database was to use SQL Server database. I will look into using SQL CE, but as I wrote earlier, it requires some customization. I believe if you want to keep developers' experience smooth, you may want to let people having a test SQL Server connection with a very limited storage that will automatically replace Debug connection string, just like Release one. But that's another topic.

    Thanks for a great support. I am closing the issue.

    • Edit

24. Vagif Abilov closed this discussion on 15 Feb, 2011 10:51 PM.