Jiri Skopalek
asked on
MSDTC communication issues on a single workstation using a WCF client cause WCF Service-wide hang affecting remaining workstations for much longer than configured timeout values dictate
Aside from removing the TransactionScope created on the WCF client (and effectively taking msdtc out of the picture), Is there an alternate way to avoid the excessively long WCF-service-wide hang when a single workstation hosting the WCF client is misconfigured (or experiencing communications issues)?
We have a simple WCF service implemented using C#, and a simple WCF Client which creates TransactionScope before invoking the WCF service proxy.
Both work fine as far as concurrency goes if Windows Firewall allows TCP communication from/to msdtc.exe thru firewall. However if a single workstation is misconfigured (i.e. has firewall enabled, and has an Inbound Rule for TCP for msdtc.exe disabled), its attempt to communicate with the service will block all other WCF clients (which are properly configured) from communicating with the WCF Service for at least 41 seconds (given the currect settings for TCP retransmissions), despite us using much shorter timeout settings for the WCF binding as well as for the TransactionScope timeout.
The WCF service is decorated with
[System.ServiceModel.Servi ceBehavior (
InstanceContextMode = System.ServiceModel.Instan ceContextM ode.PerCal l,
ReleaseServiceInstanceOnTr ansactionC omplete = false,
ConcurrencyMode = System.ServiceModel.Concur rencyMode. Multiple,
IncludeExceptionDetailInFa ults = false,
TransactionTimeout = "00:00:13"
)
The WCF service has a single operation contract, decorated with [System.ServiceModel.Trans actionFlow (System.Se rviceModel .Transacti onFlowOpti on.Mandato ry)] in the class interface.In the class itself, the same method is decorated with [System.ServiceModel.Opera tionBehavi or(Transac tionScopeR equired = true)].
The WCF service is hosted using a Windows console application which uses a netTcpBinding configured with transactionFlow="true" transactionProtocol="OleTr ansactions " sendTimeout="00:00:20" receiveTimeout="00:00:20"
The service is accessed from a Windows Forms client application configured with the following values for its netTcpBinding:
transactionFlow="true"
transactionProtocol="OleTr ansactions "
transferMode="Streamed"
sendTimeout="00:00:20"
receiveTimeout="00:00:20"
We have a simple WCF service implemented using C#, and a simple WCF Client which creates TransactionScope before invoking the WCF service proxy.
Both work fine as far as concurrency goes if Windows Firewall allows TCP communication from/to msdtc.exe thru firewall. However if a single workstation is misconfigured (i.e. has firewall enabled, and has an Inbound Rule for TCP for msdtc.exe disabled), its attempt to communicate with the service will block all other WCF clients (which are properly configured) from communicating with the WCF Service for at least 41 seconds (given the currect settings for TCP retransmissions), despite us using much shorter timeout settings for the WCF binding as well as for the TransactionScope timeout.
The WCF service is decorated with
[System.ServiceModel.Servi
InstanceContextMode = System.ServiceModel.Instan
ReleaseServiceInstanceOnTr
ConcurrencyMode = System.ServiceModel.Concur
IncludeExceptionDetailInFa
TransactionTimeout = "00:00:13"
)
The WCF service has a single operation contract, decorated with [System.ServiceModel.Trans
The WCF service is hosted using a Windows console application which uses a netTcpBinding configured with transactionFlow="true" transactionProtocol="OleTr
The service is accessed from a Windows Forms client application configured with the following values for its netTcpBinding:
transactionFlow="true"
transactionProtocol="OleTr
transferMode="Streamed"
sendTimeout="00:00:20"
receiveTimeout="00:00:20"
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.