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.
Related
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?
I have a WCF Web Service that has no concurrency configuration in the web.config, so I believe it is running as the default as persession. In the service, it uses a COBOL Virtual Machine to execute code that pulls data from COBOL Vision files. Per the developer of the COBOL VM, it is a singleton.
When more than one person accesses the service at a time, I'll get periodic crashes of the web service. What I believe is happening is that as one process is executing another separate process comes in at about the same time. The first process ends and closes the VM down through normal closing procedures. The second process is still executing and attempting to read/write data, but the VM was shutdown and it crashes. In the constructor for the web service, an instance of the VM is created and when a series of methods complete, the service is cleaned up and the VM closed out.
I have been reading up on Singleton concurrency in WCF web services and thinking I might need to switch to this instead. This way I can open the COBOL VM and keep it alive forever and eliminate my code shutting down the VM in my methods. The only data I need to share between requests is the status of the COBOL VM.
My alternative I'm thinking of is creating a server process that manages opening the VM and keeping it alive and allowing the web service to make read/write requests through that process instead.
Does this sound like the right path? I'm basically looking for a way to keep the Virtual Machine alive in a WCF web service situation and just keep executing code against it. The COBOL VM system sends me back locking information on the read/writes which I can use to handle retries or waits against.
Thanks,
Martin
The web service is now marked as:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
From what I understand, this only allows a single thread to run through the web service at a time. Other requests are queued until the first completes. This was a quick fix that works in my situation because my web service doesn't require high concurrency. There are never more than a handful of requests coming in at a time.
I built a application with 5 wcf services and hosted them in IIS 7.5. I used the default configuration for the net.Tcp port (808*).
I am not used to host WCF services in IIS (I always hosted in Windows Services) and I found interesting that when I call the service (using tcp binding) I got two different process on the server.
One is SMSvcHost.exe (the one that is actually using the 808 port) and the other is w3wp.exe wich I think is handling a instance of the server I am calling.
I have a lot of questions so I will enumerate them:
Should I use IIS instead of Windows Service to host WCF Services (tcp binding) ?
The fact that I have two processes to answer my request means that I may have cpu impacts ?
Sometimes my services stop answering using the tcp binding. I got a timeout error on my clients but the mex is correctly answering if I go to the http://myServer/Service1.svc. I suspect that this problem is caused by fault connections but I am throwing exceptions correctly (using fault exceptions) and catching them correctly on my clients. Besides, I am also implementing a partial class for every service to dispose corretly (either using Close or Abort methods). Is there any way to figure out what's going on when the services stop answering ?
Shouldn't the w3wp.exe processes be closed after the client ends the request ? They remain on the Task Manager even when no one is using the services. I guess this is the reason of why my Entity Library logging locks the file after my request is completed.
Ideally it would be better hosted in Windows Activation Services (WAS) which is close to what you think of as IIS, but not quite. Here's a good introductory article on MSDN magazine:
http://msdn.microsoft.com/en-us/magazine/cc163357.aspx
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.