I have searched about, how to know if WCF service is down OR not and I came to know that the only way to know this is to call WCF service method. We can create a method that just return true.
In my case I want to show a message when service is down to the client and for other exceptions of WCF service, I want to show the exceptions as it is. What should be the best way to this ?
If the service is yours then go ahead and use that method that returns true.
However, you should just go ahead and consume the service, as it's not necessarily true that it will remain up the entire time that you consume it. Handle your interim timeouts and errors gracefully for all of your operations and show your messages accordingly.
One client-side thing you can do is send a WebRequest and see if it returns a HttpStatusCode.OK but it can't promise you that the service won't fail or is running.
During your consuming the service you can expect FaultException, proxy and channel state errors, invalid configuration (bindings, etc) and CommunicationException objects.
You can read more on this on MSDN.
From there:
Communication errors occur when a network is unavailable, a client uses an incorrect address, or the service host is not listening for incoming messages. Errors of this type are returned to the client as CommunicationException or CommunicationException-derived classes. Application errors occur during the execution of a service operation. Errors of this kind are sent to the client as FaultException or FaultException.
This problem can be solved only "client side", because server can reply with "true" only if WCF service is running and well configured.
All the other case should be managed from client.
In a simple way you can call that simple service if it reply it seems all OK, otherwise you'll get a faultexception or an exception that you need to catch.
Pay attention at async / await, you need to catch exception in the closer place to the web call otherwise you'll get an uncaught application exception that will crash app domain.
Related
We have an existing WCF client that receives data from a WCF service. We have one specific business logic implemented in client side that will execute only if EndpointNotFoundException found from WCF call. Recently we received a very specific requirement where the same logic needs to be executed for some special business scenario. However, due to business constraint, we dont have flexibility to modify code in client side. Hence, we started thinking that if it is possible to raise force EndpointNotFoundException from service so that same code can be executed in client if EndpointNotFoundException received from service. Problem is, WCF service always send a fault contract exception even we raise EndpointNotFoundException from service. My question is, is there any way to raise EndpointNotFoundException from service so that client can receive exact same error instead any fault exception.
Your inputs will be highly appreciated. This is very critical from business point of view.
I got it, if I set the status code of the request as 404 not found, ultimately at client end it will throw as EndpointNotFoundException exception.If the request has processed successfully.
WebOperationContext ctx = WebOperationContext.Current;
ctx.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.NotFound;
My service is running currently on
localhost:17722/Book.svc
How can my client app know if the service running before trying to consume it?
Don't check to see if a server is up before consuming it. Consume the service and handle any errors that occur during the call.
Even if you check that the service is up it can go down between the time you check that it is up and you call the service. So even if you check that it is up, you still need to handle it being down when you consume it.
The best way to check if a service is up is to try to use it.
Only some kind of ping
but without guarantee, that after you ping was ok the service will be not droped before your real request
To summarize:
Prepare you clint to handle dead service(s), faults etc
I would apply the principal of Tell, don't ask in this situation. Just try to perform whatever operation you were intending on doing, and then handle the exception if it fails.
Why would your program be consuming a service if it was not necessary to the operation of the program?
Hey service, can I invoke your 'X' method? ... no? ... okay, I didn't want to anyway :P
Well this is not possible until you try the service (or ping the server). Calling your web service from your client application is like calling any other web service, how can you know that a "google's" web service is running before consuming it?
Once I had a similar problem and I just expose an operation that returns "something" (return true for instance) that I called to know if the server application was "operational" and expecting a "timeout" or "500" error when not working.
Setup a dummy method in the svc that returns a bool or something. Then hit it on a background thread at a specified interval. If the request times out you can then handle the timeout by displaying something that says the service is unreachable.
We are creating a web service request for IBM Maximo web services in C#.net , the issue is apart from for few web service requests we get succesful response for all other web services, but for some requests there is no response at all, but when we give request for the same using the SOAP UI, we get response.
Where would the problem be ? Any ideas?.
Many thanks ,
byfour
Any ideas?
Start debugging. First of all, of course your application contains logging, so you can see whether any exceptions occur while sending the message.
If no exceptions occor on your end, you can configure tracing to log all actions the WCF plumbing is executing, so you can see whether that part goes well. If it does, you can start debugging the network. If you see your message going over the wire, it's time to pick up the phone and call the other party and ask if they see anything happening after they receive your messages.
I'm using WCF to communicate to a 3rd party REST/JSON service. Since it's WCF, I create a channel and send requests through it using WebHttpBinding and WebHttpBehavior. I am the client consuming the service. Is it possible for my channel to be stuck in a faulted state (where I would have to call Abort and recreate it to continue using it)? I have tried using it to make calls that return 404 errors or 500 errors and subsequent requests on the same instance of the channel still succeed.
It makes sense to me that it wouldn't fault, because this type of service is very disconnected compared to other services.
WebHttpBinding doesn't use sessionful channel so error on the service will not fault the channel but you should still correctly handle closing and aborting channel in case of communication exceptions etc.
I'm programming a monitoring application that needs to display the state of several windows services. In the current version, I can know whether a service is Running, Stopped, Suspended or in one of the pending states. That's good, but I'm wondering if there is a way to test if a service is actually responding? I guess it can be in a running state but not responding at all!
I am using the ServiceController class from System.ServiceProcess. Do you think that if a service is not responding, the ServiceController.Status would return an exception?
How would you approach the problem?
Thanks
EDIT
Seems that: ServiceController.Status can return 2 types of exceptions:
System.ComponentModel.Win32Exception: An error occurred when accessing a system API.
System.InvalidOperationException: The service does not exist as an installed service.
Nothing about reactivity.
This might be obvious, but have you tried talking to the service?
There's no common way to talk to a service, so there is no way Windows can interrogate whether the service is still responding as normal. It is perfectly normal for a service to go into a complete sleep waiting for external I/O to happen, and thus Windows would not get a response while the service is actually alive and functioning exactly as designed.
The only way is to actually send a request to it, and wait for the response, and for that you need some inter-process communication channel, like:
Network
Named pipes
Messages
Basically, if you need to determine if a service is able to respond, you need to check if it is responding.
The service controller types and APIs can only provide information on the basis of the service's response to those APIs.
E.g. you can create a service which responds to those APIs correctly, but provides no functionality on even numbered hours.
In the end you need to define "responsive" in terms of the services functionality (e.g. a batch processor is processing batches) and provide a mechanism (A2A API, WMI, Performance Counters) to surface this.