ManualWorkflowSchedulerService and DelayActivity

re: ManualWorkflowSchedulerService and DelayActivity

http://www.louisvuittonreplicago.com — Sat, 08 Sep 2012 23:50:15 GMT

This has been quite open-handed of people like you to offer freely what exactly many people could possibly have supplied as an electronic book to get some profit for themselves, chiefly seeing that you could possibly have done it in the event you decided. The tactics as well acted to provide a good way to be sure that the rest have the identical dream the same as my personal own to find out very much more pertaining to this condition.http://www.louisvuittonsau.com

re: ManualWorkflowSchedulerService and DelayActivity

Damir Dobric — Mon, 23 Jun 2008 15:56:27 GMT

re: ManualWorkflowSchedulerService and DelayActivity

garrone — Mon, 23 Jun 2008 15:50:51 GMT

Hi! :)

I have found a way to solve that issue. I had to inherit the WorkflowSchedulerService base class. The only 2 methods needed to be overriden are the `Schedule` ones. The first one is called when the workflow is started - which is executed in one of my threads as the workflow is started from there, and the second one (which provides a callback method) is executed in workflow runtime thread, but as I can get my own thread pool and start the execution of the rest of the workflow in it.

Both links were helpful! :) Thanks again.

re: ManualWorkflowSchedulerService and DelayActivity

Andreas Erben — Fri, 20 Jun 2008 09:36:36 GMT

regarding my previous comment to garronne....

I see you used UseActiveTimers... my comment did not take that into consideration.

re: ManualWorkflowSchedulerService and DelayActivity

Damir Dobric — Thu, 19 Jun 2008 16:49:33 GMT

This could be helpful: developers.de/.../about-manually-scheduling-and-persistance-of-workflows.aspx

re: ManualWorkflowSchedulerService and DelayActivity

Andreas Erben — Thu, 19 Jun 2008 16:39:47 GMT

To garronne:

It is difficult to guess about what might cause the additional threads to be created.

Here is how I understood your scenario:

You do manage your own thread pool, you do not use the .net thread pool at all.

I wonder what your implementation does already.

Are you sure you are not causing additional threads to be created by something else? what do you use in your workflows?

If you use the manual scheduler service, then you execute on the thread that is actually running.

Meaning, you need to look at the loaded workflows and run each of them individual from the specific thread you want it to run on.

how do you start your persisted threads now?

An interesting blog post in that context:

codeidol.com/.../Running-a-WF-Program-Instance

re: ManualWorkflowSchedulerService and DelayActivity

garrone — Thu, 19 Jun 2008 09:29:46 GMT

No, I think there's a misunderstanding: I have a thread pool with threads T1, T2, T3 which they will always "be there". If the host is restarted, there will be another T1, T2, T3. I don't care if they are the same or not. I also don't care if the workflow was executed first on T1, then is scheduled on T2, as long as they are threads from my thread pool. They are just worker threads, and I want to avoid as much as I can the creation of new threads. The application need to be fast. On my test, the framework decides to create a new thread (T4). Assuming we have 100 threads in my thread-pool, and all of them are executing workflows which need to be persisted at some point, and then all of them are resumed at the same time, we end up having 200 threads instead of 100.

I just want to know if it's possible to hook the `wake up` event and schedule on one of my own threads the resumed workflow.

re: ManualWorkflowSchedulerService and DelayActivity

Damir Dobric — Thu, 19 Jun 2008 08:52:19 GMT

I’m concerned about that design, because:

1. When the WF is persisted on Thread T1. What should happen with that thread as long the WF is in persisted state. To keep it opened is not a good idea. If you abort it, you will never again be able to do reload anything in that thread, because it does not exist anymore.

2. What when the host is started again? The there is no thread which has previously hosted persisted WF.

re: ManualWorkflowSchedulerService and DelayActivity

garrone — Thu, 19 Jun 2008 08:24:22 GMT

Yes, I am using manual-scheduler to start the workflows. My problem is after the workflow is persisted into db, and then it need to be `waked` up - the scheduler uses another thread than from my thread-pool. I want to decide on what thread the revived workflow should be executed.

This behaviour looks similar with default-scheduler, but my problem is I want to manage the waiting-queue too (it has to be stored on db, etc).

re: ManualWorkflowSchedulerService and DelayActivity

Damir Dobric — Wed, 18 Jun 2008 21:55:39 GMT

If you redehydrated persisted workflow on the same thread it was running at the moment of persisting, the you can run it on the same thread by using of manual scheduler service.

However, this scenario seems to be a bit unusual, because theoretically it will and should never be the same thread. Persistence is also done for purpose of keeping of WF session state and it should survive host crash. What will you do if the host is restarted and WF then redehydrated . In this case there is even no theoretical solution.

Hope this helps...

re: ManualWorkflowSchedulerService and DelayActivity

garrone — Wed, 18 Jun 2008 21:06:01 GMT

I have read your article, and it does sounds interesting. However, I have a problem which seems to be close to what you wrote here, and you might have an ideea an give me a hint:

I have an Application which hosts a thread pool which is supposed to run some sequential workflows. I am using ManualWorkflowSchedulerService(true). My problem is that when some workflow is "persisted", when waked up, it runs into a different thread - other than the ones from my thread pool. Is there any way I can "force" the runtime to pick one thread from my own thread pool?

Bests.

re: ManualWorkflowSchedulerService and DelayActivity

Damir Dobric — Thu, 03 Apr 2008 06:30:47 GMT

Be also aware of this: support.microsoft.com/.../821268

re: ManualWorkflowSchedulerService and DelayActivity

Damir Dobric — Tue, 01 Apr 2008 14:06:13 GMT

I would also recommend this article: blogs.msdn.com/.../583392.aspx