Mahjayar's WebLog. : WCF (Indigo)

DbSyncProvider WCF Based Synchronization– Memory Performance Analysis Of DataSet Binary SerializationFormat Vs DataSet Surrogates

Mahjayar — Tue, 10 Mar 2009 11:02:00 GMT

I had posted earlier about the memory performance when using default DataSet serialization behavior vs. using a Surrogate. Users had some questions on how the DataSet surrogate compared with the DataSet’s Remoting SerializationFormat. With .Net Fx 2.0 DataSet shipped support for serializing DataSet in Binary in addition to the default XML format. I decided to do a quick test comparing the serialization memory usage between the two optimizations. Here is a simple table detailing the memory usage.

I used a Toshiba Tecra laptop running Windows 7 Beta build with 2GB RAM. The DataSet contains one DataTable which contains one string column. Each column is a 5Mb string. Size is Peak working set. The BinaryFormatter serializes the DataSet in to a MemoryStream.

No of Rows	BinaryFormat Serialization (MB)	Surrogate Serialization (MB)
1	34.1	34.5
5	131.6	131.39
10	271.1	271.39
48	1116.1	1118.1
50	Out of Memory	1024
51	Out Of Memory	Out Of Memory

As you can see the memory performance is pretty similar to both the options but the Surrogate approach is able to handle slightly more data than the Binary format. The Binary format peaked at 48 rows while the Surrogate approach peaked at 50 rows. I like the Surrogate approach as it gives the users complete control on the way data is serialized and has option for further user defined optimizations. Further the option to pick DataSet Binary serialization format is not available in the Compact framework which means Surrogates might be the only viable option (as opposed to writing a new serializer) for devices. Next I will compare the wire size of the actual serialized data.

Here is the link for original Microsoft KB article on the Surrogate approach. http://support.microsoft.com/kb/829740.

DbSyncProvider: Improving Memory Performance In WCF Based Synchronization

Mahjayar — Thu, 02 Oct 2008 06:16:00 GMT

Users have frequently wanted the ability to remotely synchronize relational nodes in a peer to peer fashion using SyncServices for ADO.NET. We have a sample demonstrating remote synchronization by using Windows Communication Foundation (WCF). I wanted to use this post to provide an easy way to optimize the performance of this WCF based solution. DbSyncProvider enumerates all changes in a DataSet and this gets applied on the destination provider. The moment the two providers are moved from a local 2-tier model to a remote n-tier model this DataSet has to be serialized and transmitted over the network. DataSet’s are very efficient when the amount of data involved is very small. The moment your data exceeds few hundred rows the amount of memory required to serialize/deserialize this DataSet is quite huge. Further the serialized size of the DataSet on disk is quite big as well.

DataSet object is by default serialized in XML format and serializing/deserialzing this XML data creates a lot of transient objects resulting in a spike in your memory usage. When you have enough data in the DataSet, like synchronizing large number of database rows, your app has the potential to go out of memory deserializing it. Infact users of SyncServices for ADO.NET V2 are quite aware of the OutOfMemoryException when they are synchronizing large number of records in the 2-tier model (PS: Solving this is the highest priority for us in the next release). Using the WCF solution increases the likelihood of this error happening even for mid sized data that fits fine in memory.

There is an easy way to optimize this problem and obliviously it requires users to move away from the XML based default DataSet serialization. Since DataSet doesn’t support any other format, the only way is to use a Surrogate to serialize it. Microsoft Knowledge base has a wonderful article detailing this Surrogate and it can be downloaded from http://support.microsoft.com/kb/829740.

Download it and use it in your WCF based Synchronization apps and you should see vast improvement in your memory usage and performance.

I wrote a quick sample checking the process peak memory usage during serialization/deserialization of a DataSet. Here are the comparison numbers between default and surrogate serialization.

The DataSet contains one DataTable which contains one string column. Each column is a 5Mb string. Size is Peak working set.

No of Rows	Default Serialization	Default Deserialization	Surrogate Serialization	Surrogate Deserialization
1	41 Mb	41 Mb	36 Mb	19 Mb
5	184 Mb	165 Mb	61 Mb	60 Mb
10	298 Mb	320 Mb	112 Mb	111 Mb
50	Out Of Memory	NA	524 Mb	523 Mb

Point proven :). As you can see for each 5Mb of data added in memory the default serialization takes anywhere from 6-8 times more memory. For 50 rows (approx 250Mb data size in memory) the serialization step itself fails with OOM.

.Net 3.5 and Visual Studio 2008 released

Mahjayar — Thu, 22 Nov 2007 04:14:00 GMT

Just like that the .Net train continues to move along to the next version of the framework. Microsoft announced on Monday the availability of .Net 3.5 and Visual Studio 2008. Its the third version of .Net that I had the privilege of working on starting from 2.0. I didnt have an opportunity to own any one particular feature in .Net 3.5 as I had moved on to the Silverlight project. My personal favorite features are the Visual Studio F5 experience for WCF services, Uri templates and Syndication API's.

You can read more about this release from Soma's blog. http://blogs.msdn.com/somasegar/archive/2007/11/19/visual-studio-2008-and-net-framework-3-5-shipped.aspx.

Here are the download locations.

.NET Framework v3.5	http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en
.NET Framework v2.0 (x86) SP1	http://www.microsoft.com/downloads/details.aspx?FamilyId=79BC3B77-E02C-4AD3-AACF-A7633F706BA5&displaylang=en
.NET Framework v2.0 (x64) SP1	http://www.microsoft.com/downloads/details.aspx?FamilyId=029196ED-04EB-471E-8A99-3C61D19A4C5A&displaylang=en
.NET Framework v2.0 (IA64) SP1	http://www.microsoft.com/downloads/details.aspx?FamilyId=32E77AE0-96EF-4ECD-A157-9BF61A7C8DAA&displaylang=en
.NET Framework v3.0 SP1	http://www.microsoft.com/downloads/details.aspx?FamilyId=EC2CA85D-B255-4425-9E65-1E88A0BDB72A&displaylang=en

Next stop: Silverlight!

Microsoft releasing .NET framework source code

Mahjayar — Thu, 04 Oct 2007 01:06:00 GMT

Microsoft is releasing the source code for the framework libraries. Read more about it here. Its not like you couldnt do this earlier. You could always have used .Net Reflector but having the ability to step in to the framework classes while debugging is neat. Looks like plans are on for releasing the source code for WCF as well!

WCF Extensibility - Plugging in custom message processing logic

Mahjayar — Thu, 15 Mar 2007 07:58:00 GMT

I have talked a lot about WCF's extensibility model and I never knew how much of the core functionality can be extended until a recent deep dive session with one of our customers developing on WCF. The client had a multi tier application with the middle tier using SOAP based messaging to communicate with the back end. They wanted to investigate using WCF for the middle tier and hence the deep dive session. They did the hard job of creating ServiceContract's for all the functionality the WCF middle tier service will expose. The customer had invested heavily in current pipeline that handled processing and dispatch of the incoming SOAP messages to the backend and wanted to reuse that. The ServiceContract they developed had lots of Operations and this posed additional overhead on the logic port. Their ideal solution would be to somehow transform the SOAP message coming in from WCF to a format matching the format as expected by the backend.

Basically they wanted to avoid implementing the huge ServiceContract and just plug in a small wrapper that will perform the transform. The first solution that comes to mind is to implement a "facade Contract" that had one generic operation that accepted and returned a SOAP message and that did the message transformation. This was an acceptable solution but this meant that clients generating proxy to this facade contract will not have all the Operations of the original contract. The customer also wanted to retain functionality provided by individual operations like addressing and additional custom header information for a required context that could be used by the backend that was lost when using one generic operation. They wanted to avoid serializing and deserializing incoming and outgoing arguments as they could be large and hence avoid the performance hit from such conversions.

Some extensibility points that come to mind for this scenario are IInstanceProvider and IOperationInvoker. IInstanceProvider was ruled out coz the need was to extend the actual Operation invoked on the instance not extend the way instances were created. Ideally we ended up with an extensibility model that used IOperationInvoker and IDispatchMessageFormatter and here is how it works.

All Operations of the ServiceContract will have one input Message parameter and return a Message. Passing Message's as parameter/return value means that WCF runtime will not serialize/deserialize the Message and hence the user app needs to work with the Message.
Have a dummy implementation of the ServiceContract that has no implementations for all the operations. Host this dummy instance as a singleton instance for the ServiceHost. In this solution, the dummy instance would never be invoked.
Implement an IOperationInvoker to plug in to the operation invoke logic.
Implement an IDispatchMessageFormatter to plug in to the serialization/deserialization logic of the incoming arguments and passing them to the IOperationInvoker.

Let’s see how this extensibility processes an incoming request.

Runtime invokes custom IOperationInvoker to allocate memory for the input parameters. Since we have one argument, allocate memory for one single object.
Runtime then invokes custom IDispatchMessageFormatter.DeserializeRequest and passes the input Message with the memory created in step 1. It’s in this step that the user will do the transformation from WCF to backend format. It then puts this transformed message to the memory created in step 1.
Runtime passes the dummy instance, populated memory from step 2 to custom IOperationInvoker.Invoke. (or BeginInvoke for async)
The custom IOperationInvoker will then pass the transformed message to the backend and get the return SOAP message from the backend.
Custom IOperationInvoker creates an empty output array for out parameters (we have no out params in this case) and returns the message returned by backend.
Runtime invokes custom IDispatchMessageFormatter.SerializeReply to serialize the outputs/reply passed in step 5. It’s in this stage that the extension will retransform the backend SOAP format to WCF reply Message.
Runtime returns the reply Message back to the client.

As you can see, we never use the dummy instance implementation and reduced the need for the extra serialize/deserialize step in the contract implementation to invoke the back end. Result - Another happy customer :)

Since this extension has no effect on the way messages are received/sent by WCF's runtime, all the message and transport level security options continue to work. When this extension is coupled with IInstanceContextProvider, IInstanceProvider, Custom Channels we can practically replace the all major operations of WCF runtime.

A sample program showing off the above extensibility is attached.

Maheshwar Jayaraman

WCF Runtime Components

Mahjayar — Sat, 23 Dec 2006 01:49:00 GMT

After I posted my earlier entry on debugging WCF apps, I thought it would be a good idea to explain the different WCF runtime blocks . This way users can see how each block/class fits in the bigger picture and how the runtime processes new channels/messages. When Open() is called on a ServiceHost, the runtime is built from the ServiceDescription and the list of ServiceEndpoints specified. Once the Open() step completes, the runtime is immutable and any attempt to modify any components results in an exception.

Let's see how the runtime looks once all listeners have been started.

Based on your base addresses and EndpointAddress, the service host contains a list of listen URI's and each URI will have its own listener. There is a ChannelDispatcher associated with each ListenUri and each ChannelDispatcher can contain 1 or more EndpointDispatcher object. Most often a ChannelDispatcher will contain exactly one EndpointDispatcher but for the case where the user has hosted multiple endpoints all using one listen URI(refer this post). In that case, there will be exactly one ChannelDispatcher for that Uri but it will contain all the EndpointDispatchers for all the ServiceEndpoints. Basically, each ServiceEndpoint added to the host will have one EndpointDispatcher associated with it. Each EndpointDispatcher contains the DispatchRuntime class that contains extension points InstanceContextProvider, InstanceContextInitializers etc.

Each ChannelDispatcher contains one ListenerHandler which, as its name suggests, handles the underlying IListener. This class is the one which determines when to accept a new channel. When the ListenerHandler accepts a new Channel, it will wrap it with a ChannelHandler object. ChannelHandler handles messages off one particular channel in the same way ListenerHandler handles connection requests from one listener.

Let's see a sample breakdown of how a channel is accepted and messages are read till the channel closes. Note that I have tried to simplify this as explaining the actual process would be very verbose.

ServiceHost is opened and all Listeners are ready to accept.
ListenerHandler object opens and issues a pending Accept() call
When a client connects to the listener a callback is fired on the ListenerHandler notifying availability of a channel.
The ListenerHandler creates a ChannelHandler object and associated the channel with that handler.
The ChannelHandler object is registered. Once registered, the ChannelHandler will try to read messages from that channel.In other words, it issues a pending Receive on that channel.
When the client sends a message, ChannelHandler is notified of that message via a callback.
The handler then determines the EndpointDispatcher that the message is addressed to.
Then using the DispatchRuntime of that EndpointDispatcher it determines the Operation that the runtime should invoke and schedules the invocation.
It keeps reading Messages from the channel till null is received (Denoting a client initiated Close())

So we refer to the ListenerHandler's way of reading channels as ChannelPump and similarly the ChannelHandler's behavior is referred as MessagePump. It's the responsibility of the individual handlers to ensure that their respective pumps are never stalled. A stalled pump will mean either no new connections are accepted or no new message will be read off a channel. The ListenerHandler uses the ServiceThrottleBehavior.MaxConcurrenctConnections throttle to determine when to pause and restart the ChannelPump and the ChannelHandler will use the ServiceThrottleBehavior.MaxConcurrenctCalls throttle to determine when to pause and restart the MessagePump.

Maheshwar Jayaraman

Debugging WCF Applications - What all I look for.

Mahjayar — Wed, 13 Dec 2006 07:28:00 GMT

When I am debugging any WCF runtime bug, I classify it in two categories. One that needs IDE (simple logic bugs) and others that need WinDbg. Every one is familiar with the IDE debugging and will leave that topic for another day. Today I wanted to talk a little bit about how I debug WCF bugs that require Windbg. Usually bugs that involve dumps are varied but if I had to pick the common ones then it would the following ones.

Server appears "hung" and is not processing messages.
Client requests are timing out even when server is not loaded.

Note: Concrete classes are in bold and field names of classes are in italics.

Since I dont have too much information on what the contract is, and what modes (ConcurrencyMode/InstanceContextMode) the ServiceHost is configured, thats the first thing I find out. I usually look for ServiceHost objects and then dump the object.

0:006> !do 01273750
Name: System.ServiceModel.ServiceHost
MethodTable: 50e4279c
EEClass: 50e4271c
Size: 136(0x88) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79104f64 4000915       28       System.Boolean 0 instance        0 aborted
79104f64 4000916       29       System.Boolean 0 instance        0 closeCalled
50e51310 4000917        4 ...ct+ExceptionQueue 0 instance 00000000 exceptionQueue
790f9c18 4000918        8        System.Object 0 instance 0127391c mutex
79104f64 4000919       2a       System.Boolean 0 instance        0 onClosingCalled
79104f64 400091a       2b       System.Boolean 0 instance        0 onClosedCalled
79104f64 400091b       2c       System.Boolean 0 instance        1 onOpeningCalled
79104f64 400091c       2d       System.Boolean 0 instance        1 onOpenedCalled
79104f64 400091d       2e       System.Boolean 0 instance        0 raisedClosed
79104f64 400091e       2f       System.Boolean 0 instance        0 raisedClosing
79104f64 400091f       30       System.Boolean 0 instance        0 raisedFaulted
79104f64 4000920       31       System.Boolean 0 instance        0 traceOpenAndClose
790f9c18 4000921        c        System.Object 0 instance 01273750 eventSender
50e385f0 4000922       24         System.Int32 0 instance        2 state
7910d61c 4000923       10 System.EventHandler 0 instance 00000000 Closed
7910d61c 4000924       14 System.EventHandler 0 instance 00000000 Closing
7910d61c 4000925       18 System.EventHandler 0 instance 0128fae0 Faulted
7910d61c 4000926       1c System.EventHandler 0 instance 00000000 Opened
7910d61c 4000927       20 System.EventHandler 0 instance 00000000 Opening
79104f64 4002bde       32       System.Boolean 0 instance        1 initializeDescriptionHasFinished
50dfecb0 4002bdf       34 ...meKeyedCollection 0 instance 01273928 baseAddresses
50e2068c 4002be0       38 ...patcherCollection 0 instance 012739b8 channelDispatchers
7910ca9c 4002be1       64      System.TimeSpan 1 instance 012737b4 closeTimeout
50df0118 4002be2       3c ...erviceDescription 0 instance 0128fc14 description
00000000 4002be3       40                       0 instance 012739f4 extensions
00000000 4002be4       44                       0 instance 00000000 externalBaseAddresses
00000000 4002be5       48                       0 instance 01293234 implementedContracts
50dfe788 4002be6       4c ...nceContextManager 0 instance 01273a30 instances
7910ca9c 4002be7       6c      System.TimeSpan 1 instance 012737bc openTimeout
50de4e78 4002be8       50 ...rformanceCounters 0 instance 00000000 servicePerformanceCounters
50dfe9f4 4002be9       54 ...r.ServiceThrottle 0 instance 01273a58 serviceThrottle
50e1ed28 4002bea       58 ...erviceCredentials 0 instance 00000000 readOnlyCredentials
50e0b9c0 4002beb       5c ...orizationBehavior 0 instance 012acc84 readOnlyAuthorization
00000000 4002bec       60                       0 instance 00000000 UnknownMessageReceived
7a746d44 4002bdd      74c           System.Uri 0   static 01273880 EmptyUri
790f9c18 4003075       74        System.Object 0 instance 01271bf4 singletonInstance
79101058 4003076       78          System.Type 0 instance 0128fb00 serviceType
50e4f74c 4003077       7c ...ontractCollection 0 instance 01290d20 reflectedContracts
7910c914 4003078       80   System.IDisposable 0 instance 00000000 disposableInstance

In this case you can see that the singletonInstance object is not null which means the InstanceContextMode is Single. You can also infer that if the disposableInstance object is not null. Other way of finding what the InstanceContextMode was to check for InstanceContextProviders and the name of InstanceContextProviders will provide you information on what kind of mode was used (0 = PerSession, 1=PerCall and 2=Single). The serviceType field will tell you the type of contract the host is hosting and with that information you can dig for the actual contract implementation class.

0:006> !dumpheap -type InstanceContextProvider
Address       MT     Size
0129f780 50dff25c       20
total 1 objects
Statistics:
      MT    Count    TotalSize Class Name
50dff25c        1           20 System.ServiceModel.Dispatcher.SingletonInstanceContextProvider

When you dump details of any IInstanceContextProvider, you can see that it contains the DispatchRuntime object associated with that provider. Dumping the DispatchRuntime gives you lot of information. For instance the DispatchRuntime object has a field called concurrencyMode that tells me what the ConcurrencyMode of the contract was (0-Single, 1-Multiple and 2-Reentrant).

0:006> !do 0129f780
Name: System.ServiceModel.Dispatcher.SingletonInstanceContextProvider
MethodTable: 50dff25c
EEClass: 50dff1e4
Size: 20(0x14) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
50e30180 400328b        4 ...r.DispatchRuntime 0 instance 0129ed50 dispatchRuntime
50e183ac 4003469        8 ...l.InstanceContext 0 instance 0129f7a0 singleton
790f9c18 400346a        c        System.Object 0 instance 0129f794 thisLock
0:006> !do 0129ed50
Name: System.ServiceModel.Dispatcher.DispatchRuntime
MethodTable: 50e30180
EEClass: 50e30110
Size: 112(0x70) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
50e2bf6c 4002fd1        4 ...horizationManager 0 instance 00000000 serviceAuthorizationManager
00000000 4002fd2        8                       0 instance 00000000 externalAuthorizationPolicies
50ddbab8 4002fd3       50         System.Int32 0 instance        0 securityAuditLogLocation
50e3ca64 4002fd4       54         System.Int32 0 instance        0 concurrencyMode
79104f64 4002fd5       64       System.Boolean 0 instance        1 suppressAuditFailure
50e0a434 4002fd6       58         System.Int32 0 instance        0 serviceAuthorizationAuditLevel
50e0a434 4002fd7       5c         System.Int32 0 instance        0 messageAuthenticationAuditLevel
79104f64 4002fd8       65       System.Boolean 0 instance        1 automaticInputSessionShutdown
50e1eae0 4002fd9        c ...ChannelDispatcher 0 instance 00000000 channelDispatcher
00000000 4002fda       10                       0 instance 0129ee1c inputSessionShutdownHandlers
50e38924 4002fdb       14 ...ndpointDispatcher 0 instance 0129ebd4 endpointDispatcher
50dfd8e8 4002fdc       18 ...IInstanceProvider 0 instance 00000000 instanceProvider
50e5c730 4002fdd       1c ...ceContextProvider 0 instance 0129f780 instanceContextProvider
50e183ac 4002fde       20 ...l.InstanceContext 0 instance 0129f7a0 singleton
79104f64 4002fdf       66       System.Boolean 0 instance        1 ignoreTransactionMessageProperty
00000000 4002fe0       24                       0 instance 0129ee58 messageInspectors
50e4b3ec 4002fe1       28 ...erationCollection 0 instance 0129edd0 operations
50e628c8 4002fe2       2c ...OperationSelector 0 instance 00000000 operationSelector
50dc9cbc 4002fe3       30 ...her.ClientRuntime 0 instance 012f0fc0 proxyRuntime
50dd8040 4002fe4       34 ...leDispatchRuntime 0 instance 012a881c runtime
00000000 4002fe5       38                       0 instance 0129ee94 instanceContextInitializers
79104f64 4002fe6       67       System.Boolean 0 instance        0 isExternalPoliciesSet
79104f64 4002fe7       68       System.Boolean 0 instance        0 isAuthorizationManagerSet
7910db30 4002fe8       3c ...ronizationContext 0 instance 00000000 synchronizationContext
50e421e0 4002fe9       60         System.Int32 0 instance        1 principalPermissionMode
790f7ab4 4002fea       40          System.Void 0 instance 00000000 roleProvider
79101058 4002feb       44          System.Type 0 instance 0128fb00 type
50e07e68 4002fec       48 ...DispatchOperation 0 instance 0129eed0 unhandled
79104f64 4002fed       69       System.Boolean 0 instance        0 transactionAutoCompleteOnSessionClose
79104f64 4002fee       6a       System.Boolean 0 instance        0 impersonateCallerForAllOperations
79104f64 4002fef       6b       System.Boolean 0 instance        1 releaseServiceInstanceOnTransactionComplete
50dc9e08 4002ff0       4c ...haredRuntimeState 0 instance 0129edc0 shared

Then I generally check the throttle limit sets on the serviceHost by dumping the serviceThrottle object. This also tells me how many throttles (Call/InstanceContext/Session) has been handed out.

0:006> !do 01273a58
Name: System.ServiceModel.Dispatcher.ServiceThrottle
MethodTable: 50dfe9f4
EEClass: 50dfe984
Size: 36(0x24) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
50e37290 400349b        4 ...cher.FlowThrottle 0 instance 01273b54 calls ==>We will dump this as a sample
50e37290 400349c        8 ...cher.FlowThrottle 0 instance 01273c10 sessions
50e03a04 400349d        c ...her.QuotaThrottle 0 instance 00000000 dynamic
50e37290 400349e       10 ...cher.FlowThrottle 0 instance 00000000 instanceContexts
50e5e99c 400349f       14 ...l.ServiceHostBase 0 instance 01273750 host
79104f64 40034a0       1c       System.Boolean 0 instance        1 isActive
790f9c18 40034a1       18        System.Object 0 instance 01273af0 thisLock
0:006> !do 01273b54
Name: System.ServiceModel.Dispatcher.FlowThrottle
MethodTable: 50e37290
EEClass: 50e37220
Size: 36(0x24) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
790fed1c 400327b       18         System.Int32 0 instance       16 capacity
790fed1c 400327c       1c         System.Int32 0 instance        0 count
790f9c18 400327d        4        System.Object 0 instance 01273b78 mutex
79113c8c 400327e        8 ...ding.WaitCallback 0 instance 01273b34 release
00000000 400327f        c                       0 instance 01273b84 waiters
790fa3e0 4003280       10        System.String 0 instance 01273ab8 propertyName
790fa3e0 4003281       14        System.String 0 instance 01273afc configName

For example you can see that in this case the Call throttle is set to 16 (default) and the count is 0 which means no throttles have been acquired. In cases when the count value is equal to capacity then you can check the waiters object to see which client is waiting for a call throttle. This applies to any FlowThrottle class.

If I wanted to see how many InstanceContext's have been issued by the runtime, then I check the instances property on ServiceHost which points the collection manager. You can dump the items array to see each individual InstanceContext.

0:006> !do 01273a30
Name: System.ServiceModel.Dispatcher.InstanceContextManager
MethodTable: 50e5e584
EEClass: 50e5e50c
Size: 40(0x28) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79104f64 40009df       18       System.Boolean 0 instance        0 aborted
790fed1c 40009e0        c         System.Int32 0 instance        1 busyCount
50e08e90 40009e1        4 ...mmunicationWaiter 0 instance 00000000 busyWaiter
790fed1c 40009e2       10         System.Int32 0 instance        0 busyWaiterCount
790f9c18 40009e3        8        System.Object 0 instance 0127391c mutex
50e26624 40009e4       14         System.Int32 0 instance        0 state
790fed1c 4003488       20         System.Int32 0 instance        2 firstFreeIndex
50e6e258 4003489       1c ...extManager+Item[] 0 instance 012f11d0 items

With the handle to InstanceContext, you can then check for the list of sessionful open channels that are associated with the InstanceContext at that time.

0:006> !do 0129f7a0
Name: System.ServiceModel.InstanceContext
MethodTable: 50e183ac
EEClass: 50e18334
Size: 112(0x70) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79104f64 4000915       28       System.Boolean 0 instance        0 aborted
79104f64 4000916       29       System.Boolean 0 instance        0 closeCalled
50e51310 4000917        4 ...ct+ExceptionQueue 0 instance 00000000 exceptionQueue
790f9c18 4000918        8        System.Object 0 instance 0129f81c mutex
79104f64 4000919       2a       System.Boolean 0 instance        0 onClosingCalled
79104f64 400091a       2b       System.Boolean 0 instance        0 onClosedCalled
79104f64 400091b       2c       System.Boolean 0 instance        1 onOpeningCalled
79104f64 400091c       2d       System.Boolean 0 instance        1 onOpenedCalled
79104f64 400091d       2e       System.Boolean 0 instance        0 raisedClosed
79104f64 400091e       2f       System.Boolean 0 instance        0 raisedClosing
79104f64 400091f       30       System.Boolean 0 instance        0 raisedFaulted
79104f64 4000920       31       System.Boolean 0 instance        0 traceOpenAndClose
790f9c18 4000921        c        System.Object 0 instance 0129f7a0 eventSender
50e385f0 4000922       24         System.Int32 0 instance        2 state
7910d61c 4000923       10 System.EventHandler 0 instance 00000000 Closed
7910d61c 4000924       14 System.EventHandler 0 instance 00000000 Closing
7910d61c 4000925       18 System.EventHandler 0 instance 00000000 Faulted
7910d61c 4000926       1c System.EventHandler 0 instance 00000000 Opened
7910d61c 4000927       20 System.EventHandler 0 instance 00000000 Opening
79104f64 400346d       32       System.Boolean 0 instance        0 autoClose
50e20c74 400346e       34 ....InstanceBehavior 0 instance 012a88c8 behavior
50e5d498 400346f       38 ...iceChannelManager 0 instance 0129f828 channels
50e1b4f8 4003470       3c ...tanceContextFacet 0 instance 012f1308 concurrency
00000000 4003471       40                       0 instance 00000000 extensions
50e5e99c 4003472       44 ...l.ServiceHostBase 0 instance 01273750 host
50e03a04 4003473       48 ...her.QuotaThrottle 0 instance 00000000 quotaThrottle
50dfe9f4 4003474       4c ...r.ServiceThrottle 0 instance 00000000 serviceThrottle
790fed1c 4003475       64         System.Int32 0 instance        1 instanceContextManagerIndex
790f9c18 4003476       50        System.Object 0 instance 0129f810 serviceInstanceLock
7910db30 4003477       54 ...ronizationContext 0 instance 00000000 synchronizationContext
50e0b340 4003478       58 ...tanceContextFacet 0 instance 00000000 transaction
790f9c18 4003479       5c        System.Object 0 instance 01271bf4 userObject
79104f64 400347a       33       System.Boolean 0 instance        1 wellKnown
00000000 400347b       60                       0 instance 00000000 wmiChannels
79104f64 400347c       68       System.Boolean 0 instance        0 isUserCreated
50e6393c 400346b      8c4 ...textEmptyCallback 0   static 012f13bc NotifyEmptyCallback
50dde148 400346c      8c8 ...ntextIdleCallback 0   static 012f13dc NotifyIdleCallback
0:006> !do 0129f828
Name: System.ServiceModel.ServiceChannelManager
MethodTable: 50e5d498
EEClass: 50e5d420
Size: 64(0x40) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79104f64 40009df       18       System.Boolean 0 instance        0 aborted
790fed1c 40009e0        c         System.Int32 0 instance        0 busyCount
50e08e90 40009e1        4 ...mmunicationWaiter 0 instance 00000000 busyWaiter
790fed1c 40009e2       10         System.Int32 0 instance        0 busyWaiterCount
790f9c18 40009e3        8        System.Object 0 instance 0129f81c mutex
50e26624 40009e4       14         System.Int32 0 instance        0 state
790fed1c 400347f       34         System.Int32 0 instance        0 activityCount
50e08e90 4003480       1c ...mmunicationWaiter 0 instance 00000000 activityWaiter
790fed1c 4003481       38         System.Int32 0 instance        0 activityWaiterCount
50e6393c 4003482       20 ...textEmptyCallback 0 instance 00000000 emptyCallback
50dc8564 4003483       24 ...Channels.IChannel 0 instance 00000000 firstIncomingChannel
50e60abc 4003484       28 ...ChannelCollection 0 instance 00000000 incomingChannels
50e60abc 4003485       2c ...ChannelCollection 0 instance 012f3ca8 outgoingChannels
50e183ac 4003486       30 ...l.InstanceContext 0 instance 0129f7a0 instanceContext

The channels field in InstanceContext points to the Sessionful channels collection which when dumped will give you list of all channels when the incomingChannels field is accessed. If you determine the ConcurrencyMode to be Reentrant then its possible that some requests can be queued in the InstanceContext when its actively servicing a message. This information can be found by dumping the concurrency field in InstanceContext.

0:006> !do 012f1308
Name: System.ServiceModel.Dispatcher.ConcurrencyInstanceContextFacet
MethodTable: 50e1b4f8
EEClass: 50e1b488
Size: 20(0x14) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79104f64 4002fc0        c       System.Boolean 0 instance        0 Locked
00000000 4002fc1        4                       0 instance 00000000 calloutMessageQueue
00000000 4002fc2        8                       0 instance 00000000 newMessageQueue

calloutMessageQueue is the queue which holds the message which when processing made an outgoing call. The newMessageQueue denotes the new messages coming in that are waiting for the InstanceContext to finish processing the message.

Coming back to the channels collection in InstanceContext, you can pick any one channel from the list and when you dump it, it will be of type ServiceChannel. This is the internal representation of all WCF channels. Like the DispatchRuntime, the ServiceChannel also provides lot of information.

0:006> !do 012f0ebc
Name: System.ServiceModel.Channels.ServiceChannel
MethodTable: 50dcd674
EEClass: 50dcd5fc
Size: 152(0x98) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79104f64 4000915       28       System.Boolean 0 instance        0 aborted
79104f64 4000916       29       System.Boolean 0 instance        0 closeCalled
50e51310 4000917        4 ...ct+ExceptionQueue 0 instance 00000000 exceptionQueue
790f9c18 4000918        8        System.Object 0 instance 012f0f54 mutex
79104f64 4000919       2a       System.Boolean 0 instance        0 onClosingCalled
79104f64 400091a       2b       System.Boolean 0 instance        0 onClosedCalled
79104f64 400091b       2c       System.Boolean 0 instance        1 onOpeningCalled
79104f64 400091c       2d       System.Boolean 0 instance        1 onOpenedCalled
79104f64 400091d       2e       System.Boolean 0 instance        0 raisedClosed
79104f64 400091e       2f       System.Boolean 0 instance        0 raisedClosing
79104f64 400091f       30       System.Boolean 0 instance        0 raisedFaulted
79104f64 4000920       31       System.Boolean 0 instance        0 traceOpenAndClose
790f9c18 4000921        c        System.Object 0 instance 012f0ebc eventSender
50e385f0 4000922       24         System.Int32 0 instance        2 state
7910d61c 4000923       10 System.EventHandler 0 instance 012f11fc Closed
7910d61c 4000924       14 System.EventHandler 0 instance 00000000 Closing
7910d61c 4000925       18 System.EventHandler 0 instance 00000000 Faulted
7910d61c 4000926       1c System.EventHandler 0 instance 00000000 Opened
7910d61c 4000927       20 System.EventHandler 0 instance 00000000 Opening
790fed1c 400310b       7c         System.Int32 0 instance        1 activityCount ==>Denotes how many activity is being actively processed. 0 indicates the Channel is ready to be closed.
79104f64 400310c       32       System.Boolean 0 instance        1 allowInitializationUI
79104f64 400310d       33       System.Boolean 0 instance        0 allowOutputBatching
79104f64 400310e       80       System.Boolean 0 instance        1 autoClose ==>Will autoclose when the other side initiates a Close.
50dd04c8 400310f       34 ...l+CallOnceManager 0 instance 00000000 autoDisplayUIManager
50dd04c8 4003110       38 ...l+CallOnceManager 0 instance 00000000 autoOpenManager
50dcd9f0 4003111       3c ...er.IChannelBinder 0 instance 012c8cd4 binder
50e1eae0 4003112       40 ...ChannelDispatcher 0 instance 0129e898 channelDispatcher
50dc9cbc 4003113       44 ...her.ClientRuntime 0 instance 012f0fc0 clientRuntime
79104f64 4003114       81       System.Boolean 0 instance        1 closeBinder
79104f64 4003115       82       System.Boolean 0 instance        0 closeFactory
79104f64 4003116       83       System.Boolean 0 instance        0 didIdleAbort ==>Did the idle timer expire
79104f64 4003117       84       System.Boolean 0 instance        0 didInteractiveInitialization
79104f64 4003118       85       System.Boolean 0 instance        0 doneReceiving ==>Usually means the Channel is done receiveing replies for all outstanding requests
50e38924 4003119       48 ...ndpointDispatcher 0 instance 0129ebd4 endpointDispatcher
79104f64 400311a       86       System.Boolean 0 instance        1 explicitlyOpened ==> Was it autoopened or explicitly opened
00000000 400311b       4c                       0 instance 00000000 extensions
50dc8618 400311c       50 ...iceChannelFactory 0 instance 00000000 factory
79104f64 400311d       87       System.Boolean 0 instance        1 hasSession
50e4331c 400311e       54 ...essionIdleManager 0 instance 012f1168 idleManager
50e183ac 400311f       58 ...l.InstanceContext 0 instance 0129f7a0 instanceContext
50dfe9f4 4003120       5c ...r.ServiceThrottle 0 instance 00000000 instanceContextServiceThrottle
79104f64 4003121       88       System.Boolean 0 instance        0 isPending
79104f64 4003122       89       System.Boolean 0 instance        0 isReplyChannel
50dbc7d0 4003123       60 ...l.EndpointAddress 0 instance 00000000 localAddress
50dc3874 4003124       64 ...ls.MessageVersion 0 instance 0129658c messageVersion
79104f64 4003125       8a       System.Boolean 0 instance        0 openBinder
7910ca9c 4003126       8c      System.TimeSpan 1 instance 012f0f48 operationTimeout
790f9c18 4003127       68        System.Object 0 instance 00000000 proxy
50dfe9f4 4003128       6c ...r.ServiceThrottle 0 instance 01273a58 serviceThrottle
790fa3e0 4003129       70        System.String 0 instance 00000000 terminatingOperationName
50e183ac 400312a       74 ...l.InstanceContext 0 instance 00000000 wmiInstanceContext
79104f64 400312b       8b       System.Boolean 0 instance        0 wasChannelAutoClosed
00000000 400312c       78                       0 instance 00000000 unknownMessageReceived

Digging through the binder field in ServiceChannel will give you the IChannelBinder which will hold a reference to the ChannelHandler object that is responsible for pumping messages from that Channel. If you feel that messages from a particular connected client is not being processed it could be that he ChannelHandler is not pumping messages. I say connected because only channels that have been accepted by the runtime will be having a ChannelHandler object. If there is no session throttles left then clients will timeout in their Open() call itself.

0:006> !do 012c8df0
Name: System.ServiceModel.Dispatcher.ChannelHandler
MethodTable: 50e07bd0
EEClass: 50e07b58
Size: 104(0x68) bytes
(C:\WINDOWS\assembly\GAC_MSIL\System.ServiceModel\3.0.0.0__b77a5c561934e089\System.ServiceModel.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
50dec920 40031b6       4c ...ndler+RequestInfo 1 instance 012c8e3c requestInfo
50dcd9f0 40031b7        4 ...er.IChannelBinder 0 instance 012c8cd4 binder
50dcd674 40031b8        8 ...ls.ServiceChannel 0 instance 012f0ebc channel
79104f64 40031b9       3c       System.Boolean 0 instance        0 doneReceiving ==>Indicates all messages have been pumped from the Channel
50dcddf0 40031ba        c ...plexChannelBinder 0 instance 012c8cd4 duplexBinder
79104f64 40031bb       3d       System.Boolean 0 instance        1 hasRegisterBeenCalled
79104f64 40031bc       3e       System.Boolean 0 instance        1 hasSession
50e5e99c 40031bd       10 ...l.ServiceHostBase 0 instance 01273750 host
79104f64 40031be       3f       System.Boolean 0 instance        0 incrementedActivityCountInConstructor
79104f64 40031bf       40       System.Boolean 0 instance        0 isCallback
79104f64 40031c0       41       System.Boolean 0 instance        0 isPumpAcquired
79104f64 40031c1       42       System.Boolean 0 instance        0 isChannelTerminated
79104f64 40031c2       43       System.Boolean 0 instance        0 isConcurrent ==>0 indicates Single ConcurrencyMode
79104f64 40031c3       44       System.Boolean 0 instance        0 isManualAddressing
50e139b0 40031c4       14 ...r.ListenerHandler 0 instance 012acb8c listener ==>Listener off which Messages are received
50dc3874 40031c5       18 ...ls.MessageVersion 0 instance 0129658c messageVersion
50dfe854 40031cc       1c ...rHandlingReceiver 0 instance 012c8e70 receiver
79104f64 40031cd       45       System.Boolean 0 instance        0 receiveSynchronously ==>Indicated whether the pump is sync or async
79104f64 40031ce       46       System.Boolean 0 instance        0 receiveWithTransaction
50e65618 40031cf       20 ...ls.RequestContext 0 instance 00000000 replied
50e65618 40031d0       24 ...ls.RequestContext 0 instance 00000000 requestWaitingForThrottle
50e4bab4 40031d1       28 ...rappedTransaction 0 instance 00000000 acceptTransaction
50dfe9f4 40031d2       2c ...r.ServiceThrottle 0 instance 01273a58 throttle
79104f64 40031d3       47       System.Boolean 0 instance        1 wasChannelThrottled
50dfe9f4 40031d4       30 ...r.ServiceThrottle 0 instance 00000000 instanceContextThrottle
50e60c28 40031d5       34 ...actedBatchContext 0 instance 00000000 sharedTransactedBatchContext
00000000 40031d6       38 ...actedBatchContext 0 instance 00000000 transactedBatchContext
79104f64 40031d7       48       System.Boolean 0 instance        0 isMainTransactedBatchHandler
7910ca9c 40031b5      844      System.TimeSpan 1   static 012c8e80 CloseAfterFaultTimeout
79107d2c 40031c6      848 System.AsyncCallback 0   static 012c8ec0 onAsyncReceiveComplete
79113c8c 40031c7      84c ...ding.WaitCallback 0   static 012c8ee0 onContinueAsyncReceive
79113c8c 40031c8      850 ...ding.WaitCallback 0   static 012c8f00 onStartSyncMessagePump
79113c8c 40031c9      854 ...ding.WaitCallback 0   static 012c8f20 onStartAsyncMessagePump
79113c8c 40031ca      858 ...ding.WaitCallback 0   static 012c8f40 onStartSingleTransactedBatch
79113c8c 40031cb      85c ...ding.WaitCallback 0   static 012c8f60 openAndEnsurePump

Think I should stop at this for today. Some of the information here should be useful for all end user developers (like throttles). Due to our extensive testing, end users should never have to worry about debugging some classes (like ChannelDispatcher) unless they implement their own channel stack and want to know why the ChannelDispatcher is not pumping messages off their channel. Hopefully this will gives you enough information to go and dig around your server dumps and try to figure out where the bottle neck could be (Waiting for throttle/Waiting for reentrance/waiting for new message to be received etc).

Next time I will talk about how to debug the client side ServiceChannel (in case of timeouts) and talk a little bit more about input queues on the server.

Maheshwar Jayaraman

WCF Channels AutoOpen vs Open Semantics

Mahjayar — Mon, 20 Nov 2006 03:57:00 GMT

Wanted to write up a post on whats the difference between "auto" opening a WCF Channel and explicitly calling "Open" on it. Michael Maruchek posted a detailed and well explained post at http://blogs.msdn.com/mjm/archive/2006/11/13/auto-open-part-1.aspx. Waiting for part 2.

Since Micheal did such a wonderful job of explaining the design I just wanted to illustrate the behavior with a sample app.

I have a simple contract that has a Sync and Async version and the client will invoke a operation on the async contract 10 times. Lets see the difference in actual behavior when the channel is auto opened and explicitly opened.

First the contract definitions.

[ServiceContract(Name="ISyncService")]

public interface IAsyncService

{

[OperationContract(AsyncPattern=true, Action="SayHello")]

IAsyncResult BeginSayHello(int id, AsyncCallback callback, Object obj);

void EndSayHello(IAsyncResult ar);

}

[ServiceContract]

public interface ISyncService

{

[OperationContract(Action="SayHello")]

void SayHello(int id);

}

Here is the contract implementation. Notice the multiple concurrency that should allow concurrent processing of multiple messages.

[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple, InstanceContextMode=InstanceContextMode.Single)]

public class SyncService : ISyncService

{

#region ISyncService Members

public void SayHello(int id)

{

Console.WriteLine("SayHello invoked with Id: {0}", id);

Thread.Sleep(500);

}

#endregion

}

Finally the client code to invoke the service. We will introduce a small sleep to simulate some long processing.

IAsyncService channel = ChannelFactory<IAsyncService>.CreateChannel(binding, new EndpointAddress(ServiceAddress));

for (int i = 0; i < 10; i++)

{

channel.BeginSayHello(i, SayHelloCallback, channel);

}

This implies the "auto" open behavior. Lets see the output.

Issued all asynchronus requests. Waiting for them to complete.
SayHello invoked with Id: 0
SayHello invoked with Id: 1
SayHello invoked with Id: 2
SayHello invoked with Id: 3
SayHello invoked with Id: 4
SayHello invoked with Id: 5
SayHello invoked with Id: 6
SayHello invoked with Id: 7
SayHello invoked with Id: 8
SayHello invoked with Id: 9
All async requests completed

As you can see no matter how many times the client is run the server processes all the async invocations sequentially and in the order it was issued. This defeats the purpose of issuing async calls and having multiple concurrency mode on the server.

Lets see the output when the channel is explicitly opened. I just added the following line before issuing the requests.

((IChannel)channel).Open();

Output is:

Issued all asynchronus requests. Waiting for them to complete.
SayHello invoked with Id: 0
SayHello invoked with Id: 2
SayHello invoked with Id: 4
SayHello invoked with Id: 5
SayHello invoked with Id: 1
SayHello invoked with Id: 3
SayHello invoked with Id: 7
SayHello invoked with Id: 6
SayHello invoked with Id: 8
SayHello invoked with Id: 9
All async requests completed

As you can see the output is truly async and truly concurrent.

Maheshwar Jayaraman

WinFx: UseSynchronizationContext Usage

Mahjayar — Wed, 08 Nov 2006 09:25:00 GMT

One of the most common problems we debug with WCF proxies invoked from WinForm/XAML app's is a perceived hang when duplex contract's are involved. The app usually has a "click to invoke proxy" button that invokes a method (which will callback the client) on the server and the app will freeze waiting for the response. I wanted to talk a little bit more about this today that hopefully will prove useful if anyone is debugging similar issues.

Most often the reason for this behavior is due to a argument in the ServiceBehaviorAttribute/CallbackBehaviorAttribute class called UseSynchronizationContext. This property indicates that the WCF runtime will schedule all calls to the server/callback dispatcher on the SynchronizationContext that was captured when the runtime was built. Refer to these links to know more about SynchronizationContext. SynchronizationContext is used to ensure that a synchronous/async callback is invoked on the same thread. People who have worked with winforms would know about this. Basically to modify any control on winform, the caller must access the the control on the same thread in which the controls were created or else you get this wonderful error message.

An unhandled exception of type 'System.InvalidOperationException' occurred in System.Windows.Forms.dll
Additional information: Cross-thread operation not valid: Control 'button1' accessed from a thread other than the thread it was created on.

If the callback is invoked on the SynchronizationContext of the thread that created the control this problem can be avoided. WCF allows the user to specify whether the WCF should invoke operations (on server) or callbacks (on clients) on a particular SynchronizationContext. This property defaults to true in both attributes and what this implies is that if WCF detects a SynchronizationContext during the creation of the runtime then it will cache it and will streamline all further invocations on that. By default console programs dont have SynchronizationContext set (i.e SynchronizationContext.Current will be null) and so this is not a problem for those applications. Winforms, on the other hand, will populate a SynchronizationContext object when the Form constructor is called and so when you create a ServiceHost/Proxy/ChannelFactory within the scope of the winform (or in any of the winform event code), its cached by the runtime. I will use this simple duplex contract to explain the problem.

[ServiceContract(CallbackContract = typeof(IDownloadCallbackService))]
public interface IDownloadService
{
[OperationContract]
void Download();
}
public interface IDownloadCallbackService
{
[OperationContract]
void DownloadComplete();
}

The client is a simple winform app that has one button and in the click event of the button, it creates a duplex channel to the service and invokes the Download operation. The server will just invoke the callback channel and call DownloadComplete.

//Server implementation

public void Download()
{
Console.WriteLine("CLient invoked download");
OperationContext.Current.GetCallbackChannel<IDownloadCallbackService>().DownloadComplete();
Console.WriteLine("Notified client of download complete");
}

//Callback implementation on the client

public void DownloadComplete()
{
MessageBox.Show("Server notified that download is complete");
}

//Client code to create a duplex channel

private void button1_Click(object sender, EventArgs e)
{
DuplexChannelFactory<IDownloadService> factory = new DuplexChannelFactory<IDownloadService>(typeof(DownloadCallbackService), new WSDualHttpBinding());
IDownloadService client = factory.CreateChannel(new InstanceContext(new DownloadCallbackService()), new EndpointAddress("http://localhost:8080/DownloadService"));
client.Download();
((IClientChannel)client).Close();
}

So the sequence is Client->Download->DownloadComplete->returns to Download->returns to Client. Since the duplex channel was created in the button click event, the SynchronizationContext of the winform app is captured and when a message for DownloadComplete arrives at the client's dispatcher it will schedule the processing of the message on that SynchronizationContext. This message will not be processed as the the SynchronizationContext is busy waiting for the Download call to complete and Download is blocked on the server waiting for DownloadComplete and hence the deadlock.

Solution is to set UseSynchronizationContext property to false on the CallbackBehavior attribute.

[CallbackBehavior(ConcurrencyMode=ConcurrencyMode.Reentrant, UseSynchronizationContext=false)]
public class DownloadCallbackService : IDownloadCallbackService

If you see similar problem on server and the server is hosted in a winforms app then set UseSynchronizationContext=false on the ServiceBehaviorAttribute.

One final comment, the UseSynchronizationContext is checked when the DuplexChannelFactory is created. When using the DuplexChannelFactory model to create channels as shown above, ensure that the type passed in the constructor is the type of class on which the CallbackBehavior is defined. For example, if the factory is created as show below, then the runtime will not be able to look up a CallbackBehavior and hence will use the default values.

DuplexChannelFactory<IDownloadService> factory = new DuplexChannelFactory<IDownloadService>(typeof(IDownloadService), new WSDualHttpBinding());

Maheshwar Jayaraman[WCF]

WinFx 3.0 has RTM'd

Mahjayar — Tue, 07 Nov 2006 09:14:00 GMT

Sometime last Friday, admist cheers and high fives, our lead PM resolved the last bug that stopped us from signing off on WCF(code named Indigo). Bug # 1 was opened way back when Indigo was in planning stages and with this bug we signed off on the product. Today Microsoft announced RTM of the .Net 3.0. For more information read the .NetFx blog at http://www.netfx3.com/blogs/news_and_announcements/archive/2006/11/06/.NET-Framework-3.0-has-been-released_2100_.aspx.

WCF is the second product RTM'ing since I started working at Microsoft and it really satisfying to ship such a product. On to next version now.

Maheshwar Jayaraman

What happens when InstanceContext.Release/GetServiceInstance() is called on a Singleton

Mahjayar — Wed, 25 Oct 2006 03:56:00 GMT

InstanceContext has two methods, ReleaseServiceInstance and GetServiceInstance, that can be used by users to dynamically release and create new service instances. Service instance is the actual .Net instance of the contract on which operations are invoked. This post is to clarify the behavior of the API's when the service is hosted as a Singleton. There are two overloads in ServiceHost that lets users host a contract as singleton. If users use the overload that requires a Type then the runtime will create a instance of the class during the Open() process. If users use the Object overload then the runtime will use that instance to service all requests. The instance created in the former case is referred as "hidden" singleton and the one passed by the user in the latter case is called "well-known" singleton. The behavior of InstanceContext.Release/GetServiceInstance is different in both cases.

Technically whenever the user calls InstanceContext.ReleaseServiceInstance() the runtime will disassociate the instance from the InstanceContext and call dispose (If the instance inherits from IDisposable) on the instance. A new instance will be created when a new message arrives for that endpoint or the user explicitly calls InstanceContext.GetServiceInstance().

When ReleaseServiceInstance is called on a hidden singleton, the runtime disassociates the hidden instance from the InstanceContext but will not dispose it yet. When another message arrives for that endpoint or GetServiceInstance is called a new instance is created which will now act as the singleton instance for all future requests. This now acts as a normal service instance and so when the user calls Release/GetServiceInstance is called that instance will be disposed immediately and a new one created. The hidden singleton that was disassociated in the first call to ReleaseServiceInstance will be disposed only when the ServiceHost is closed. So even though the InstanceContextMode was set to Single, there can be 2 service instances active in the appdomain if the user calls ReleaseServiceInstance.

In case of well-known singleton, the runtime detects that its well-known and will ignore all calls to Release/GetServiceInstance i.e its just a no-op invoking those two API's. This well-known instance will never be disposed by WCF (not even during ServiceHost.Close() process) as this user owns the lifetime of the instance and the user owns the responsibility of disposing it.

Lets host a simple contract to see the behavior in both cases.

[ServiceContract]
public interface IService
{
    [OperationContract]
    void SayHello();
    [OperationContract]
    void ReleaseInstance();
}

The class that implements this contract will give a unique ID to each instance created and will implement IDisposable so it can log when that instance is disposed by the runtime.

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Single)]
public class MyService : IService, IDisposable
{
    int sayHelloCount;
    String id;
    public MyService()
    {
        id = Guid.NewGuid().ToString();
        Console.WriteLine("MyService Ctor called. Id = "+ id);
        sayHelloCount = 0;
    }
    #region IService Members
    public void SayHello()
    {
        sayHelloCount++;
        Console.WriteLine("SayHello count : " + sayHelloCount);
    }
    public void ReleaseInstance()
    {
        OperationContext.Current.InstanceContext.ReleaseServiceInstance();
        OperationContext.Current.InstanceContext.GetServiceInstance();
    }
    #endregion
    #region IDisposable Members
    public void Dispose()
    {
        Console.WriteLine("Destructor called for Id : " + id);
    }
    #endregion
}

The SayHello() method will print the number of times it was invoked by all clients and the ReleaseInstance() when called will explicitly refresh the service instance.

Hidden Singleton Host:

Lets consider the case when the contract is hosted as a hidden singleton. The client will create call SayHello() thrice followed by ReleaseInstance() for a couple of times.

IService client = ChannelFactory<IService>.CreateChannel(new BasicHttpBinding(), new EndpointAddress("http://localhost:8080/MyService"));
client.SayHello();
client.SayHello();
client.SayHello();
client.ReleaseInstance();
client.SayHello();
client.SayHello();
client.SayHello();
client.ReleaseInstance();
client.SayHello();
client.SayHello();
client.SayHello();

The output when we run the above client is provided below.

MyService Ctor called. Id = 420f1d1b-aa68-452a-91ab-4021650b33a5
SayHello count : 1
SayHello count : 2
SayHello count : 3
Calling ReleaseServiceInstance
Calling GetServiceInstance
MyService Ctor called. Id = 349b5842-5e80-4033-a076-4a7b27017b4e
SayHello count : 1
SayHello count : 2
SayHello count : 3
Calling ReleaseServiceInstance
Destructor called for Id : 349b5842-5e80-4033-a076-4a7b27017b4e
Calling GetServiceInstance
MyService Ctor called. Id = bec7b3c6-2658-4193-b6c7-0ad6f2fdc32c
SayHello count : 1
SayHello count : 2
SayHello count : 3

Calling ServiceHost.Close()
Destructor called for Id : bec7b3c6-2658-4193-b6c7-0ad6f2fdc32c
Destructor called for Id : 420f1d1b-aa68-452a-91ab-4021650b33a5
Press any key to continue . . .

As you can see the runtime creates the hidden singleton "3cee8466-39ff-4d3e-a671-1ea8e73066bb" and then uses it to service the first three SayHello calls. Then when the user calls ReleaseInstance there is no log for the the instance being disposed. The subsequent call to GetServiceInstance creates another instance with id "149273da-2c02-4b90-a1f4-d36e87d6991d". This serves the next three calls and when the user calls and will be disposed the next time ReleaseServiceInstance is called. The hidden singleton is disposed only when the ServiceHost is closed. The Destructor called for "bec7b3c6-2658-4193-b6c7-0ad6f2fdc32c" denotes the singleton InstanceContext being closed and that inturn closing the service instance (As this instance is no longer the hidden singleton).

Well-Known Singleton case:

Lets take a look at the output in case of well-known singleton.

MyService Ctor called. Id = d224f9d8-25dd-459d-b6be-c71477ecc20e
SayHello count : 1
SayHello count : 2
SayHello count : 3
Calling ReleaseServiceInstance
Calling GetServiceInstance
SayHello count : 4
SayHello count : 5
SayHello count : 6
Calling ReleaseServiceInstance
Calling GetServiceInstance
SayHello count : 7
SayHello count : 8
SayHello count : 9
Calling ServiceHost.Close()
Press any key to continue . . .

As you can see there us no effect of calling ReleaseServiceInstance/GetServiceInstance and that the instance is never disposed.

The sample program is attached.

Maheshwar Jayaraman [WCF]

IInstanceContextProvider threading model

Mahjayar — Thu, 19 Oct 2006 09:20:15 GMT

IInstanceContextProvider is the extension used by WCF runtime to associate/create InstanceContexts for every Message being processed. As I mentioned earlier this extension is called for every message arriving on every channel. This means that two messages from the same channel can race with each other in trying to get an InstanceContext. This is not an issue for InstanceContextMode.PerCall and InstanceContextMode.Single for obvious reasons. In case of PerCall each message gets its own InstanceContext and in Single case the Singleton is established when the ServiceHose is opened and so every message will get the same InstanceContext. So if you are using the extension to custom wire your InstanceContext creation/association logic then you need to be aware of the potential race. To make matters simple I am going to take an example of user implementing the PerSession behavior. Lets see a sequence when the first n messages from a sessionful channel are processed by the host. I talk about the first n messages only, as once the InstanceContext has been created and associated with the Channel then each message can easily look it up. Lets take a look at sequence for the first 2 messages (different colors for different threads)

Channel1->Message1->IInstanceContextProvider.GetExistingInstanceContext() ==>No InstanceContext exists yet so null is returned.

Channel1->Message2->IInstanceContextProvider.GetExistingInstanceContext() ==>No InstanceContext exists yet as Message1 has not completed InitializeInstanceContext() yet and so null is returned.

Channel1->Message1->IInstanceContextProvider.InitializeInstanceContext() ==>New InstanceContext was created and is associated with the sessionful channel.

Channel1->Message2->IInstanceContextProvider.InitializeInstanceContext() ==>One more InstanceContext was created and now that will be associated with the channel.

So when Message2 from Channel1 starts processing and IInstanceContextProvider is invoked, its on a different thread and this now races with Message1.InitializeInstanceContext() running on a different thread. If null is returned from GetExistingInstanceContext() for both messages and so two new InstanceContext's are created. So based on how many messages arrive before the InstanceContext is hooked to the sessionful channel, the system can potentially create that many InstanceContexts for the same channel. If Message1 runs through both the methods before any other message is processed for the same channel then there is no issue.

The solution is to make the second message block in GetExistingInstanceContext() till the first message completes initializing the InstanceContext. For more details on how to achieve this, refer to the SDK sample shipping with WCF under (TechnologySamples\Extension\Instancing\Sharing).

So another question is whether this is an issue only for ConcurrencyMode.Multiple and the answer is no. It's an issue for all ConcurrencyMode's as that check is enforced at a later stage by the runtime.

Maheshwar Jayaraman[WCF]

WCF June/July CTP: QnA

Mahjayar — Thu, 27 Jul 2006 00:51:00 GMT

We have an internal alias where people developing apps on WCF post questions. Generally we see some questions that are commonly faced by people and thought it would be a good idea to make a quick HowTo or QnA on some topics that WCF newbie users may find useful.

Q: How to know if a server channel is sessionful or not?

A: Couple of ways.

OperationContext.Current.SessionId != null

or OperationContext.Current.Channel.SessionId != null

Q: WCF service runtime disposes off all input/output parameters once the operation is invoked. How can I cache the input arguments?

A: Mark you operation implementation with OperationBehavior with AutoDisposeParameters set to false.

[OperationBehavior(AutoDisposeParameters=false)]

public void Foo(Message m, FooDisposableObj f)

{

//Implementation

}

Q: Why is OperationContext.Current.RequestContext null?

A: Because the operation is OneWay. RequestContext is not null only for request/reply.

Q: Why does the first call on a newly created channel take longer to complete than subsequent calls?

A: Its possible that the delay is due to AutoOpen feature. If a channel is not in Opened state when a call is made then the channel is "auto opened" for the user. Users can explicitly open a channel by doing

((IClientChannel)channel).Open();

or proxy.Open() ==> If proxy is of type ClientBase

Q: If a binding does not use ReliableMessaging, then is the order preserved for all async calls made on a Channel using that binding?

A: Yes.

Q: What's the difference between ConcurrencyMode.Single and ConcurrencyMode.Reentrant. They seem to process only one message at any time?

A: Reentrant is actually analogus to ConcurrencyMode.Single in that it will process only one message at a given time. The only difference is that the service is unblocked to process a new message when the user makes an outgoing call while processing a message.

Q: If I have multiple messages/channels waiting for a throttle (Call/Session/InstanceContext), how fair is WCF to the waiters?

A: First come first serve.

Q: Whats the implications of using IsOneWay=true on an OperationContract?

A: KennyW has a wonderful post on this at http://kennyw.com/indigo/130

Q: How do I know if the throttle limit set on the ServiceHost is too restrictive?

A: Well thats a decision the customer needs to make based on the load they expect. But in test environment, enable logging and if there is too many occurances of

"The system hit the limit set for the '[One of the throttles]' throttle. Throttle value can be changed by modifying..." then it probably means that that particular throttle is too restrictive.

Thats all the time I have today for this list. There is lot more that I will try to post by the end of the week.

Maheshwar Jayaraman [WCF]

Usage pattern for IInstanceContextInitializer vs IInstanceContextProvider

Mahjayar — Mon, 17 Jul 2006 23:50:00 GMT

I mentioned in my previous post that June CTP introduces a new extension to enable sharing. One common question being raised internally is the difference between IInstanceContextProvider.InitializeInstanceContext and IInstanceContextProvider.Initialize. Both these methods are called whenever a new InstanceContext is created and so the question is why did IInstanceContextProvider duplicate this method?

Let me talk about why this method was introduced in IInstanceContextProvider. To implement sharing users need to know when a new InstanceContext is created so they can wire up the caching logic. So if we did not provide this API, users would need to implement IInstanceContextInitializer just to get this notification. Also, for sharing one needs to associate the Channel on which the message came with the InstanceContext created so that the InstanceContext lives till that Channel is functional. One look at the IInstanceContextInitializer.Initialize parameters tells us that it currently doesnt pass the Channel. So one possible solution is to change Initialize signature. But we felt that the sharing extension should be the all that the users need to worry about when designing sharing and the API's in that extension should be designed such that all necessary information is available to the implementor. So we decided to go with one interface for the extension.

The one may wonder that IInstanceContextInitializer is redundant and that it can be removed. The reason its still there is because both these interfaces are there for two very different scenarios. Think of them like two kind of saws, one a chain saw and the other a low power precision saw. IInstanceContextProvider is the heavy duty one which lets you bypass InstanceContext lifetime logic, enable sharing and InstanceContext leasing, while IInstanceContextInitializer is for more finer things like adding extensions to newly created InstanceContext.

Also, your service can have exactly one IInstanceContextProvider while it can have any number of IInstanceContextInitializer's.

Maheshwar Jayaraman[WCF]

WinFx June CTP: ServiceThrottle changes

Mahjayar — Sun, 09 Jul 2006 04:13:00 GMT

Users will find 2 changes in ServiceThrottle and ServiceThrottlingBehavior classes in WinFx's JuneCTP. First is a Property name change and second is the change to some of the default values.

1. Name changes

MaxConnections renamed to MaxConcurrentSessions

MaxInstances renamed to MaxConcurrentInstances

2. Default values

MaxConcurrentSessions default reduced to 10 (Old value was 64)

MaxConcurrentCalls default reduced to 16 (Old value was 64)

The names have been changed to reflect their actual purpose and we feel is a step in the right direction. In previous CTP's when a ServiceHost was created, then that serivce by default only throttled MaxConcurrentCalls. With June CTP, the ServiceHost throttles MaxConcurrentCalls and MaxConcurrentSessions. This means that if you dont change the throttle values then your service cannot process more than 10 concurrent sessions.

To make debugging easier, we log (Logging is done at Information level) whenever the runtime pauses processing of a Message if it is unable to acquire any throttle. To prevent polluting the log with repetitive info, logging is done only when the throttling limit is exceeded by 1.

Maheshwar Jayaraman [WCF]

Update: Corrected the text in the last but one paragraph to suggest 10 concurrent sessions as opposed to 10 sessions.