If you are deploying your workflow application to multiple machines(NLB scenario) and all these machines are using same database for persistence , you need to use following config
(1)OwnershipTimeoutSeconds should be very high value ,so other hosts can't load these workflows
(2)Disable auto unload
SAMPLE WORKFLOW CONFIG:
<WorkflowRuntime Name="WorkflowServiceContainer">
<CommonParameters>
<add name="ConnectionString" value="Initial Catalog=SHARED;Data Source=localhost;Integrated Security=SSPI;"/>
</CommonParameters>
<Services>
<add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add type="System.Workflow.Activities.ExternalDataExchangeService, System.Workflow.Activities, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" ConfigurationSection="ExternalDataExchange"/>
<add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="false" OwnershipTimeoutSeconds="5000" LoadIntervalSeconds="0" />
<add type="System.Workflow.Runtime.Hosting.DefaultWorkflowCommitWorkBatchService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add type="System.Workflow.Runtime.Tracking.SqlTrackingService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" IsTransactional="false"/>
</Services>
</WorkflowRuntime>
AFTER WE ARE DONE WITH WORKFLOW, WE CAN CALL THIS METHOD TO UNLOAD WORKFLOW MANUALLY:
StateMachineWorkflowInstance stateInstance = new StateMachineWorkflowInstance(Application["WorkflowRuntime"] as WorkflowRuntime, instanceId);
stateInstance.WorkflowInstance.Unload();
// we improved WF designer performance in .NET 3.5 sp1 , After .NET 3.5 sp1 also, you may see some designer performance problems, you can follow these guide lines to increase WF designer performance
Commonly reported issues
1. Time taken to open a workflow document is long.
2. Opening Activity bind dialog is slow.
Reasons for slow down
The Workflow designer relies on parsing the source code in the current project to provide updated design information in workflow design surface, rules dialog intellisense etc. This is mainly to enable scenarios where picking up changes from the source even before the project has been rebuilt.
Tips to make designer perform better
1. Move all types used in workflows to a different project than where the workflows live.
Move interfaces, event types, custom activities, helper classes to a different project than in which the workflow resides. E.g. in the solution from a customer, there were about 10 project, with 10 workflows each and 10 associated event types. These types are all reparsed to update to build the design time type information every time the user changes workflows in the project. Moving these to a different assembly e.g just one project with all the types needed for the 10 workflow projects will help improve performance.
2. Reduce the number of workflows in a project.
Each workflow is a type ( directly in c#/vb, and indirectly in xoml case) that needs a design time type to be built by parsing, so if there are 10 workfows in a project, opening any workflow in the project for the first time means parsing all the other workflows as well. Classifying these workflows based on their function and grouping them in 2-3 workflows per project improved performance drastically.
3. Re-Factor large state machine workflows into smaller workflows
One example we found from a customer had 780 states and 1000 activity binds in the same workflow, leading to a InitializeComponent() of about 16000 lines. Factoring this state machine into smaller reusable workflows will making designer performance much better, and reduce a lot of redundant states.
4. Don’t do long running work in activity constructors
Activity constructors are called during design time also, so doing things like connecting to a database etc should never be done in constructors, this can make the designer take too long to open workflow documents using these activities.
REFERENCE:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3808068&SiteID=1
WCF Development Improvements
.NET 3.5 SP1 and VS 2008 SP1 include several enhancements for WCF development. Some of these include:
- Significant scalability improvements (5-10x) in Web-hosted application scenarios
- Support for using ADO.NET Entity Framework entities in WCF contracts
- API usability improvements with DataContract Serializers, and with the UriTemplate and WCF web programming models
- Enhanced TestClient support within VS 2008 SP1
- New Hosting Wizard in VS 2008 SP1 for WCF Service Projects
- Improved debugging support in partial trust scenarios
DataContracts without attributes (POCO support) in .NET 3.5 SP1
http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/50934.aspx
DataContracts and object references
http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/14/50943.aspx
WCF features/improvements in .NET 3.5 SP1 & VS 2008 SP1
http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/12/50909.aspx
Orcas SP1 Improvement: Asynchronous WCF HTTP Module/Handler for IIS7 for Better Server Scalability
http://blogs.msdn.com/wenlong/archive/2008/08/13/orcas-sp1-improvement-asynchronous-wcf-http-module-handler-for-iis7-for-better-server-scalability.aspx
By default, the ManualWorkflowSchedulerService is used without active timers. So when the delay is hit, the workflow yields the thread back to the scheduler, and when the delay expires, nobody is around to call RunWorkflow. If you look in the web.config for the service you should see the entry for the scheduler service and you can add in the UseActiveTimers=true which will cause the workflow to resume when the delay expires
Example:
<add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" useActiveTimers="true"/>
useActiveTimers:
Boolean that determines how delay activities are handled. If true, the scheduler service automatically resumes workflows after delay activities expire (by using an in-memory timer). If false, the host must manually resume the workflow after the delay activities expire.
The remote SQL server's clock should be in sync with the machine's clock where the program is run.
The sqlTrackingWorkflowInstance.WorkflowEvents fetches WorkFlowEvents in a DateTime range between SqlDateTime.MinValue and DateTime.UtcNow. If the SQL machines clock is ahead of the application machines clock then events will not be fetched until the application machine's clock catches up with the events DateTime creation time.
CONCLUSION:
- Make sure your application server and Database server clock is in sync (you have to sync it to seconds also).
- make sure tracking service IsTransactional property set it to false
Example:
SqlTrackingService trackingservice = new SqlTrackingService(connectionString);
trackingservice.IsTransactional = false;
workflowRuntime.AddService(trackingservice);
// Add following config to your WCF app config file , Since we use System.net API also ,you can trace System.net API calls to debug WCF apps
<configuration>
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
<source name="System.Net.HttpListener">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
<source name="System.Net.Sockets">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
<source name="System.Net.Cache">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add
name="System.Net"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Net.trace.log"
traceOutputOptions="DateTime"
/>
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
<add name="System.Net.Sockets" value="Verbose" />
<add name="System.Net.Cache" value="Verbose" />
<add name="System.Net.HttpListener" value="Verbose" />
</switches>
</system.diagnostics>
</configuration>
If you are failed to persist the workflow or read workflow information from the Database ,workflow runtime may raise Abort event or Terminated event without raising any error messages ,so if you got Abort event or Terminate event and if you don't know why workflow fired these events, Please enable workflow trace to debug these problems
How to enable workflow trace
http://blogs.msdn.com/madhuponduru/archive/2008/01/17/workflow-trace.aspx
You can find workflow FAQ here
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=2272219&SiteID=1&mode=1
(1)Chris wrote excellent blog about Named pipe Binding
http://blogs.charteris.com/blogs/chrisdi/archive/2008/05/19/exploring-the-wcf-named-pipe-binding-part-1.aspx
http://blogs.charteris.com/blogs/chrisdi/archive/2008/06/16/exploring-the-wcf-named-pipe-binding-part-2.aspx
http://blogs.charteris.com/blogs/chrisdi/archive/2008/06/23/exploring-the-wcf-named-pipe-binding-part-3.aspx
(2)Named pipe binding security model ( http://blogs.msdn.com/drnick/archive/2008/04/01/the-pipe-dacl.aspx)
When a named pipe channel listener creates a new named pipe it has to supply a discretionary ACL that describes who can connect to the pipe. Here is how that DACL is constructed:
- An access control entry is added to deny GENERIC_ALL access to the well-known network SID (S-1-5-2).
- Access control entries are added to allow GENERIC_READ and GENERIC_WRITE access to a list of SIDs that is defined on the binding element. The default is to allow the well-known world SID (S-1-1-0). Since this list is an internal setting, you will almost always be using the default.
- An access control entry is added to allow GENERIC_READ and GENERIC_WRITE access to the well-known creator owner SID (S-1-3-0).
And that's how the DACL gets built.
There are a few other settings as well required to create the pipe if you're interested in their values. The pipe is bidirectional (PIPE_ACCESS_DUPLEX), data is written to the pipe as messages (PIPE_TYPE_MESSAGE), data is read from the pipe as messages (PIPE_READMODE_MESSAGE), we use overlapped IO (FILE_FLAG_OVERLAPPED), and if this is the first pipe created by the listener, then we need to say that more pipes are coming (FILE_FLAG_FIRST_PIPE_INSTANCE).
(3)How can I know what are the pipes opened on my machine(http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx)
Named Pipe Directory Listings:
Did you know that the device driver that implements named pipes is actually a file system driver" In fact, the driver's name is NPFS.SYS, for "Named Pipe File System". What you might also find surprising is that it’s possible to obtain a directory listing of the named pipes defined on a system. This fact is not documented, nor is it possible to do this using the Win32 API. Directly using NtQueryDirectoryFile, the native function that the Win32 FindFile APIs rely on, makes it possible to list the pipes. The directory listing NPFS returns also indicates the maximum number of pipe instances set for each pipe and the number of active instances.
To demonstrate the listing of named pipes I've written a program called PipeList. PipeList displays the named pipes on your system, including the number of maximum instances and active instances for each pipe.
(4) Sample code to Create Named Pipe
#include <windows.h>
#include <process.h>
#include <stdio.h>
HANDLE hPipe;
int Buffer_in;
int count;
int main(int argc, char* argv[])
{
hPipe = CreateNamedPipe("\\\\.\\pipe\\muller", //this machine
PIPE_ACCESS_INBOUND,
PIPE_TYPE_BYTE | PIPE_WAIT,
10, 0, sizeof(Buffer_in),
10000, // timeout in millseconds
NULL); // security descriptor
if(INVALID_HANDLE_VALUE == hPipe)
{
printf("Server Pipe not created\n");
exit(0);
}
else
printf("Successful in creating server pipe\n");
// wait of a connection.
while ( !ConnectNamedPipe(hPipe, (LPOVERLAPPED) NULL)); printf("Client has connected\n");
for(int i=0; i<10; i++)
{
ReadFile(hPipe,
(LPVOID) &Buffer_in, (DWORD) sizeof(Buffer_in), (LPDWORD) &count, (LPOVERLAPPED) NULL);
printf("revieved %d\n", Buffer_in);
}
printf("press 'c' to quit\n");
while( toupper(getchar()) != 'C');
CloseHandle(hPipe);
return 0;
}
// clientpipe.cpp : Defines the entry point for the console application.
//
#include <windows.h>
#include <process.h>
#include <stdio.h>
HANDLE hPipe;
const int BUFSIZE = 10;
int Buffer_out;
int count;
int main(int argc, char* argv[])
{
hPipe = CreateFile("\\\\.\\pipe\\muller", // this machine
GENERIC_WRITE, 0,
NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
(HANDLE) NULL);
if(INVALID_HANDLE_VALUE == hPipe)
{
printf("Server Pipe not found\n");
goto done;
}
else
printf("Successful in finding server pipe\n");
for(Buffer_out=0; Buffer_out< BUFSIZE; Buffer_out++)
{
printf("sending %d\n", Buffer_out);
WriteFile(hPipe,
&Buffer_out, sizeof(Buffer_out),
(LPDWORD) &count, NULL);
}
printf("%d integers written, press 'c' to quit\n");
CloseHandle(hPipe);
done:
while( toupper(getchar()) != 'C');
return 0;
}
MORE INFO:
If you want to know about SID
http://en.wikipedia.org/wiki/Security_Identifier
http://support.microsoft.com/kb/163846/en-us
