I have a L2S Repository class which instantiates the L2S DataContext in its constructor.
The repository is instantiated at run time (using Unity) in a service hosted in IIS with WCF.
When I run up the client MVC applicaton the calls to the backend WCF service work for a while and then timeout.
I suspected perhaps a database issue as I was depending on IIS garbage collection to dispose of unused DataContext instances in the IIS host but when I checked the characteristics of the problem I notice the following:
The client makes the call to WCF but the WCF service does not respond.
Next, the client times out
Some time later (several minutes) the service actually executes the request by instantiating the repository and servicing the call.
I have checked both client and server traces logs and only the client shows WCF errors (the timeout error).
Where should I look? Is it something in WCF or is L2S possibly blocking with unfreed conenctions, resources etc.?
Many thanks
Brian
Did not close the connection on the Client side! Dohhh!
Related
Following is the architecture of my MVC application that is built using WCF service and EF:
MVC application >> WCF Service >> Business Logic Layer >> Data access layer >> Data Store
I have created MyDbContext in Data Access layer, and it's interacting with the database.
I have created a connection string in web.config file of MVC application with the name MyDbContext. I believe this should work, but instead it is trying to create a new database on my sql server. What can be the reason? Or if I am missing anything?
If I put the connection string in web.config of WCF service, it works fine. but I believe this should be part of MVC application only, and WCF shouldn't be limited to using this connectionstring only.
If you are using WCF service to access business layer and data access layer your ASP.NET MVC application should not access the database directly - it should even don't know about database existence at all. That is the reason why you are using WCF service, isn't it? Otherwise you can delete whole your WCF service layer and call the business layer directly from ASP.NET MVC.
Connection string is not automatically transferred from MVC application through WCF call. The correct solution is to define connection string in WCF application because it is the tier where the database is accessed.
Since the WCF service is hosted in the same container which is also hosting the data access layer then it is entirely reasonable to configure it with the correct connection string.
Why would you not want to do this?
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
apologies in advance for this question being dumb, or previously covered. I have researched far and wide but have not found any resources on WCF/ Windows Services that cover this question.
I have a managed Windows Service which is working nicely. Every n (>5) seconds it checks on the status (e.g. memory consumption) of some processes and other Windows services and also does some database logging and raises events where necessary.
I intend to make an ASP.NET website that would allow users to query the status of the processes that the Windows Service is monitoring. Having researched the options it looks like the up-to-date method would be to use a WCF Service, hosted in the Windows Service, to act as intermediary between the ASP.NET website and the Windows Service. Such that, a user could request through the browser a snapshot of the current status of whatever set of processes the Windows Service was monitoring, and have this request and subsequent response relayed through the WCF service (using named pipes, I think).
So, my difficulty is that there a set of methods and events in the Windows Service for which a single root object exists (let's say MonitorObject). I don't see how the ServiceHost can be instantiated with the reference to MonitorObject so that the WCF Service can call the methods in the Windows Service. I am thinking that perhaps I need to make the Monitor object a shared (I am VB'ing) member of the Windows Service class (that contains OnStart and OnStop) and make all the events shared so that the WCF Service can just access the WindowsService.SharedMonitorObject without needing to be passed the object....
However, I am lost in the subject and am seeking any advice on how best to proceed.
Thanks in advance.
I think you're going down the right track. I wouldn't necessarily make the entire MonitorObject shared, but you might put a shared method in that object that will return the single root object to the caller.
There is a design pattern called the Singleton Pattern that will help you with this. Jon Skeet has written an excellent article on some of the things to be aware of when using this pattern in .NET. His article uses C# for the examples, but here's a SO question referencing this pattern using VB.
While it's unclear from your description, my guess is that your Windows Service is essentially single-threaded right now. Just keep in mind that once you add the WCF service, you'll need to make the methods that it references thread-safe.
I have a WCF service method which takes more than two hours to execute (runs some reports). how can I make sure that it doesn't timeout regardless of the time it takes? I think there are many timeout settings in WCF config, I am not sure which one is relevant for me. for ASMX webservices, there was an option to specify infinite timeout setting, is there a similar one for WCF?. also do I need to alter any IIS settings for this (WCF servcie is hosted in IIS), like recycling of worker processes, idle timeouts etc?
This is an abuse of web services. Don't do this.
Instead, have the web service kick off the long-running operation, running in a separate process. If the clients need to know when the reports are done, then have the "separate process" keep track of the report creation and have it note when the reports are finished. The client can call a web service to check that status.
You really don't want to be depending on an HTTP connection remaining open for hours. It's a network. Things happen on networks. Bad things.
Have you considered using callbacks? Your client sends a request and then waits for a notification from the server for when it is done? This would probably require a change in the client, but in that way, your service can "rattle the chain" and tell the client when the report is finished.
help: http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx
WCF timeouts:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/84551e45-19a2-4d0d-bcc0-516a4041943d/
You should also consider the timeouts on the client side, as well. (binding.OpenTimeout, ReceiveTimeout, CloseTimeout etc.)
Another option would be to host the WCF in a Windows Service, which could simplify your situation, as it removes IIS from the equation:
http://msdn.microsoft.com/en-us/library/ms733069.aspx
Or, what about using a one way WCF call? That way, the call will return to the client ASAP after sending the request.
Need sample fire and forget async call to WCF service
Consider creating a WCF workflow service (using WF) instead. These are specifically designed to handle long-running processes, especially if you use persistence.
My ASP.NET MVC controller constructors create an instance of a service class by supplying it with (among other things) a ModelStateWrapper (similar to this article). Since this object is handled through a reference, any changes made to it in the service are reflected when the controller accesses that ModelStateWrapper object.
I need to convert that logical service layer into WCF services that will be hosted in IIS.
Assuming I want to continue performing validation in the service layer, which approach is better?
Pass the ModelStateWrapper object by reference (possible according to MSDN) with each service operation
Keep track of errors in the service and have the client explicitly retrieve a list of errors after any/all service operations are performed
Any other suggestions or links to articles that would help me perform validation behind a WCF service?
It should be noted that these services will eventually be consumed by a variety of UIs (ASP.NET MVC, Winform, Console, maybe even third-party).
Since you already have everything in place and working, pass the ModelStateWrapper over the wire to WCF service. Let it fill it out and send back.
The other platforms can use this same wrapper to get the error information.