We have set of WCF services running on single computer which collectively serves an WPF application which could be on same machine or on remote machine (within same network only). We need failover mechanisum so whenver any of the service crashes or hangs - we want to restart the service and initialize it by calling appropriate method.
Since we are not aware of what is the industry standard for implementing failover for WCF service - we have implemented like this way. We start main WCF service hosted in console app along with one more secondary WCF service which constantly checks health of main WCF service by calling exposed method on given endpoint. If main WCF service fails, it takes role of main WCF service and launches another secondary WCF service.
The above approach is working fine but only problem we have seen is memory since we launch services in pair and every host requires 10MB of memory.
Can anyone help me what is the industry practice for implementing failover for this kind of scenario?
Related
i can't find any good architecture explanation of how can WCF SHOULD be part of a main-server with multiple clients.
in my solution, i want to have a central WCF service (hosted in windows-service on windows server machine).
The central service is the only one that's connected to the DB.
all the clients, are connecting to this main service, login, and get having a duplex communication.
via that main service, one client can connect another one. or when one client using the main service to change the DB, the main service updates all other clients.
for doing that, i added in the main service the InstanceContextMode.Single attribute, and in the windows-service, i init ServiceHost with the WCF-service singleton.
it works. so so..
i can continue and search where the problems are, and how to fix them, but it looks like something here is not right, like i'm not supposed to do it this way.
i could really use an advice on how WCF service should be used as a main service with multiple clients, that require common memory.
it's basically for ~20 clients with not too intensive operations, but i still want the option to let them all communicate simultaneously with the main service, and not only one by one.
I have developed a WCF Web Service using C# that works and serves up the data I need to my mobile client using a COBOL VM that talks to my backend data. It works, but it is very unreliable. I think it has to do with the lifecycle of the web service and I just don't understand how it is breaking down. I believe the problem is the COOBL VM, which is a singleton, and the process of shutting it down each time. I've already tried
lock(myobject)
{
... run my code here
}
I want to move the COBOL VM to a server service where I can persist my COBOL VM and just make calls to it. I don't know how to persist the COBOL VM across all WCF Web Service calls. I'm looking for examples the show a wcf web service communicating with a server service so I can move my business layer code out of the service and just have it make calls to the server service for the data it needs. This way I can keep the COBOL VM running all the time rather than going through a load-up, execute, and then shutdown process as I'm doing in the Web Service.
Does anyone have any GOOD examples of a WCF Web Service communicating with a WCF Server Service?
keep the COBOL VM running all the time rather than going through a load-up, execute, and then shutdown process as I'm doing in the Web Service.
Then create a Windows service that hosts this VM client, so you only have to connect once and can keep it running. Then you can let that service also host a WCF service, which then queries the VM client.
You might be better off looking into a CORBA solution - CORBA is the only remoting technology that can give you access into an already running process.
I have a WCF service that all clients connect to in order to get notifications \ reminders (using a CALLBACK interface they implement). Currently the WCF service is self-hosted, but the plan is to have it hosted in a Windows Service.
The WCF service has a 'Publish', 'Subscribe' and 'Unsubscribe' operations.
I need to have a background worker thread of some sort poll an SQL server database table constantly [every XXX minutes], and look for certain 'reminder' rows. Once it finds them - it should notify all the connected clients.
I thought of 2 ways of achieving this.
.
METHOD A :
Have a separate EXE project (don't want it to be a console, so what should it be - a Windows Service ?) that will start and run a background thread. The background thread will connect to the 'Reminder' service as one of its clients. The background thread will poll the database, and once it finds something - it will send a 'Publish' message to the WCF service, that will make the WCF service send the reminder to all the subscribed clients.
.
METHOD B :
Somehow make the background thread run within the WCF service project, and when it detects a new reminder row in the database, somehow make it 'signal' the WCF service with the info, and the WCF service will then send this info to all subscribed clients.
.
Which method is better ? Any other suggestions ?
If this is a long running process, a windows service is the perfect solution.
Your main Win Service thread will be polling the DB, queuing the results into some kind of supplier/consumer thread safe collection.
You can host a WCF service within the win service, which can then consume (remove) any results from the queue and pass them back to the client as requested (calls into the WCF will come in on their own thread)
This is a pretty common architecture, and not difficult to implement.
Method A:
If you were to create two separate hosts (i.e. one for the WCF service and one for the "Polling" service) then you really have only one option to make it all work nicely.
Windows Service communication is very limited (without the help of a service endpoint, e.g. WCF). Therefor, if you were to host your "Polling" service in a Windows Service, you must couple it with a WCF service anyway.
It is then feasible to host both services together in one Windows Service and by manually instantiating the WCF host and passing into the constructor a "Polling" service.
protected override void OnStart(string[] args)
{
//...
// This would be you "polling" service that would start a background thread to poll the db.
var notificationHost = new PollingService();
// This is your WCF service which you will be "self hosted".
var serviceHost = new WcfService(notificationHost);
new ServiceHost(serviceHost).Open();
//...
}
This is far from ideal because you need to communicate via events between the two services, plus your WCF service must run on singleton mode for manual instantiation to work... So this leaves you with...
Method B:
If you were to host the "Polling" services inside your WCF service, you are going to run into a number of issues.
You need to be aware of the number of instances of the "Polling" services that gets created. If your WCF service has been configured to be instantiated for every session, you could end up with too many "Polling" services and that may end up killing your db/servers.
To avoid the first issue, you may need to set a singleton WCF service, which may lead to a scaling issue in the near future where one WCF service instance is not enough to handle the number of connection requests.
Method C:
Given the drawbacks in Method A and B, the best solution would be to host two independent WCF services.
This is your regular service where you have subscriber/unsubscribe/publish.
This is your polling singleton service with subscribe/unsubscribe.
The idea is that your regular service, upon receiving a subscriber will open a new connection to your polling service or use an existing one (depending on how you configure your session) and wait for a reply. Your polling service is a long running WCF service that polls your db and publish the notification to its subscribers (i.e. the other WCF host).
Pros:
You are assured that there will be only one polling service.
You could scale your solution to host the regular service in IIS and the polling service in Windows Service.
Communication limitations is minimal between the two services and no need for events.
Test each service interdependently through their interfaces.
Low coupling and high cohesion between the services (this is what we want!).
Cons:
More services means more interfaces and contracts to maintain.
Higher complexity.
I know that it is not a good idea to have timers inside a WCF service class that is hosted inside IIS since these are meant to have short lifetimes. And from the advice here it also sounds like having a service is the best way to go for that situation.
But has anyone tried using timers inside a self-hosted service in production? We have a windows service that acts as a client and uses timers to do periodic operations at the moment.
This is fine for most cases, but I am concerned about the robustness of the design: some of the operations are critical (financial system calculation triggers). Since the WCF service and the windows service are two components, ensuring both are running is difficult.
If I moved the critical operations to a timer inside the WCF Service I remove that problem, but what else should I be concerned about then?
If I understand correctly, your question is actually about IIS-hosted WCF services, is that right?
IIS controls the application pool that your WCF service runs in. That means that IIS may decide to recycle your application pool and all the apps/services in it. Then your service only gets activated again once it is called by a client. So, scheduling in WCF services or ASP.NET applications cannot be relied on.
The picture of course changes if you can self-host your WCF service. Then there is no IIS application pooling to take into account, and you can schedule at will. Therefore, if you need the combination of WCF + scheduling, it's best to create a Windows service that will include both.
We have an existing WCF service that makes use of wsDualHttpBinding to enable callbacks to the client. I am considering moving it to netTcpBinding for better performance, but I'm quite wary of moving away from the IIS-hosted service (a "comfort zone" we currently enjoy) into having our own Windows service to host it. I was hoping we could still host this on IIS 7 but Win2K8 won't be reality for us for some time.
What things should I watch out for when creating our own Windows service to host our WCF service? Things like lifetime management and request throttling are features that come free with IIS hosting so I'd also like to know how we can effectively host our service on our own without the convenience of having IIS do the hard work for us. Thanks! :)
So as you cannot host using WAS there are a couple of things to realise.
If the service crashes it doesn't restart by default (although you can change this in service properties)
IIS will recycle the application pool if it hangs or grows too big; you must do this yourself if you want the same sort of reliability.
You must create an account for the service to run under, or use one of the default services. Resit the temptation to run the service as SYSTEM or under an administrator account; if you want to use a built in account use NETWORK SERVICE.
It becomes harder to debug in situ.
Consider using a error logger such as log4net
Having said that I deployed a WCF/Windows service combination for a customer 9 months ago; it's heavily used and hasn't died once.
You can request throttle in a Windows service, it's part of the WCF configuration. Note the defaults are very low, it is likely you will have to increase these.
Hosting in a Windows Service Application (http://msdn.microsoft.com/en-us/library/ms734781.aspx) is a good start.
If you can host your service on Vista, you can also benefit from Windows Process Activation Service (WAS). WAS is a generalization of the IIS process activation, which can be used to activate processes over non-HTTP endpoints (TCP, Named Pipe, MSMQ). To learn more about WCF hosted in WAS, read http://msdn.microsoft.com/en-us/library/ms733109.aspx. To learn how to install and configure WAS, read http://msdn.microsoft.com/en-us/library/ms731053.aspx.