I have just inherited an asp.net mvc 3 site operating on .net 4 which makes heavy use of WCF calls to a very slow external service. The site is not yet live.
One curious piece of code I've found is around the WCF client proxy usage. There is one instance created for the entire aspnet application which is shared between all threads. So, effectively a global variable.
To me, this screams danger yet the site operates without error even under load testing. There is no guard code preventing concurrent calls on the WCF client in the site.
Can someone confirm the safety of using what is essentially a singleton WCF proxy in an asp net app? Wouldn't faulting kill the proxy for all threads?
Can someone confirm the safety of using what is essentially a
singleton WCF proxy in an asp net app? Wouldn't faulting kill the
proxy for all threads?
The proxy is thread safe but as you say, it should be handled with care because it could be in a faulted state in which case the channel should be opened again. You may take a look at the following sample implementation that I have been using to reuse the same channel factory. What is expensive is the creation of the channel factory, not the channel itself.
Related
I'm developing a UWP client project which need to consume some services of a WCF server. I uses the "add service reference" tool of Visual Studio to auto generate service clients(proxies). The binding type is NetTcpBinding. Below is some code snippet which create the service client:
NetTcpBinding tcpBinding = new NetTcpBinding();
tcpBinding.Security.Mode = SecurityMode.None;
tcpBinding.Security.Transport.ClientCredentialType = TcpClientCredentialType.None;
tcpBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
MainServiceClient = new MainServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8773/MyWCF/MainService/tcp"));
The question is do I need to call OpenAsync() method of MainServiceClient? It seems the service client can be auto opened when it is first called. But I read from this article that auto-opened service client would have some performance penalty. The article was written in 2007. I just wonder if this mechanism have changed today, especially in UWP project. Can anyone share more light on this topic? Thanks!
To explain this case, you should know three ways to do WCF instance management. WCF has provided three ways by which you can control WCF service instances:Per call, Per session, Single instance.
When we configure a WCF service as per call, new service instances are created for every method call you make via a WCF proxy client.
Very often we need to maintain state between method calls or for a particular session. For those kinds of scenarios, we will need to configure the service per session. In per session, only one instance of a WCF service object is created for a session interaction.
Often we would like to create one global WCF instance for all WCF clients. To create a single instance of a WCF service, we need to configure the WCF service as Single instance mode.
And there are three ways by which you can handle concurrency for each service instance in WCF :single, multiple, and reentrant.
Single: A single request has access to the WCF service object at a given moment of time. So only one request will be processed at any given moment of time. The other requests have to wait until the request processed by the WCF service is completed.
Multiple: In this scenario, multiple requests can be handled by the WCF service object at any given moment of time. In other words, requests are processed at the same time by spawning multiple threads on the WCF server object. So you have great throughput here but you need to ensure concurrency issues related to WCF server objects.
Reentrant: A single request thread has access to the WCF service object, but the thread can exit the WCF service to call another WCF service or can also call a WCF client through callback and reenter without deadlock.
In "Instance mode = Per Session and Concurrency = Single" combination, one WCF service instance is created for every WCF client session because the WCF instance mode is set to per session. All the method are executed in a sequential manner one by one. In other words, only one thread is available for all method calls for a particular service instance.
For the above scenario, you should always open WCF client proxy explicitly before you are making any calls. Because it will maintain service state between method calls and obtain high performance.
For more detail you could refer to "WCF Concurrency (Single, Multiple, and Reentrant) and Throttling" and "Three ways to do WCF instance management".
I currently have an application whereby a user makes a request to my ASP.Net UI, which in turns makes an async call into a WCF service to keep the ASP.net thread free.
The WCF service is essentially a translation module, sat on the restricted network, and bridging the DMZ to the Trusted network. This service calls out to a Java service, which will hit the DB, and I currently have this as a synchronous call.
My WCF services are setup with ConcurrencyMode.Single, and InstanceContextMode.PerCall, so I guess that when I run out of threads on the service host, I'll start backing up requests because the UI is calling async, allowing the user to send multiple requests.
Should I be calling the Java service as an async task, like I do in the UI?
async-await is almost always a good idea. It doesn't really matter which IO you are using (in this case a network call to a java service) as long as it can benefit from treating it as an asynchronous by releasing threads while waiting for IO to complete.
Of course you would get a bigger benefit by also making the java service fully asynchronous, but it isn't necessary.
I am a beginner with WCF. When I am running the application, it works, but while the client communicates with the server, the application hangs and I can't do anything in the application while it starts communicating. Can you suggest some ideas to rectify this?
Setup an own thread to do the WCF call, one possibility is to use the Thread class, see
http://msdn.microsoft.com/en-us/library/system.threading.thread.aspx
Please note that you have to take special precautions if you process/display result coming back from a WCF call, because this will then be outside of your main UI thread (if you do not use a SynchronizationContext etc...)
The WCF Data Services client API has built in methods to call WCF Data Services asynchronously: http://msdn.microsoft.com/en-us/library/dd756365.aspx
While making my first ajax attempts, I decided also, to go to use IIS hosted WCF now. The strange thing is, that the WCF cannot process several requests parallel for the same user/session, if sessionmode is enabled! If sessionmode is disabled on asp.net, the requests are processed parallel. The broser/client may execute several different requests, where some of them are long running. This blocks all further requets and make my ajax app unusable.
This applies to asmx [webservices] also. I had a big hope, to compile the webservice methods using "IReadOnlySessionState" interface, but this has - in oppsite to webpages - no influence. But I need access [most times readonly] to the asp.net session!
Does someone knows any solution to this problems.
Anyway, thanks a lot!
br--mabra
In .NET 4, you can do this in Application_BeginRequest
if (Context.Request.Path.EndsWith("xxx.svc"))
Context.SetSessionStateBehavior(SessionStateBehavior.ReadOnly);
I found this:
http://blogs.msdn.com/silverlightws/archive/2009/09/30/having-a-pollingduplex-service-and-any-other-wcf-service-in-the-same-website-causes-silverlight-calls-to-be-slow.aspx
Which states,
"All WCF services require read/write session state access if you enable ASP.Net sessions, which causes the replies to be queued sequentially. Ideally user should be able configure the WCF handler to be read only, which would allow polling duplex services to work with sessions. Unfortunately this is unsupported at this point."
...the only thing I can think of is if there's some way to manually force early release of the lock. I'm looking into that now.
You can provide a custom session state provider
See: http://koolsand.blogspot.com/2010/02/why-iis-hosted-wcf-services-does-not.html
whenever a request contains svc in the
path it intimates default session
state provider to use readonly lock
and not read-write lock. So using
readonly lock will allow the next wcf
call to be executed concurrently.
I'm using WCF through Spring.net WCF integration link text
This works relatively fine, however it seems that WCF and Spring get in each other's way when instantiating client channels. This means that only a single client channel is created for a service and therefore the clients get a timeout after the configured timeout is expired since the same client channel has been open since it was instantiated by Spring.
To make the matters worst, once a channel goes to a fault state, it affect all users of that service since spring doesn't create a new channel for each user.
Has anyone managed to use WCF and Spring.net work together without these issues?
I've created a small library to help you with Spring.NET in these circumstances. You can find the svn repo here. More info can be found on my blog.