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.
Related
As far as I know BasicHttpBinding doesn't support ReliableSession feature. So, this means that when request is received by server (wcf host) then it will be executed wether the client is disconnected afterwards or not. I hope I'm right on this?
The problem is:
I have a WCF service with BasicHttpBinding. We tested this service by calling it 10 times with different threads on the client side. And these requests are all made at the same time (almost). Right after the callings of the thread we're terminating the program by killing the process. As a result 6 out of 10 requests are executed but the 4 of the requests aren't executed. We've checked network traffic with wireshark and saw that 10 of the requests are received by the wcf service host. However, we know that 4 of them didn't executed.
(Timeout values are not configured on binding: that means they're all setted to their defaults. Also the wcf service is hosted on iis).
What's the problem here? Where can I check? What can we do to achieve 10 execution out of 10 even if the client disconnects?
What can we do to achieve 10 execution out of 10 even if the client disconnects?
You can make it the default behavior. Use [OperationContract(IsOneWay=true)] to create a one-way contract where the client does not wait for a reply, but simply disconnects after sending the message.
Since you really need the service to be completed even if the client disconnects i think there is a database transaction that you need to be done.
In case the WCF is connecting to a database, this would be normal especially if you are using the same database user and password, if this is the case try to connect once for all WCF instances.
either way you have to make sure that your WCF provide concurrent access. click here for more information of concurrent WCF access.
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.
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;
I am using WCF with duplex netTcpBinding and I want to send a message to all users connected currently to my service. I thought I could just create a callback contract and it would send a message to all the clients but it seems I am mistaken, and there isn't a single server/service, each client gets its own service?
I have service with the name 'Server'. Here is how I access the server from the client -
ServerClient client = new ServerClient();
string result = client.SendMessage(messageTextBox.Text);
client.Close();
I thought the 'Server' was a single object that handled all calls by my clients but then I've started a thread in the Server constructor and I found out that multiple threads get started because every time a client calls the Server, a new Server object is created.
So it seems each client has it's own service/server.
With that in mind how do I send a message to all my clients from the server?
I thought the standard practise for accessing the server from the client was to get a proxy object, call the service functions, and then Close the proxy object like in the code above...but if I close the proxy object doesn't it mean I have closed the connection between client and server and now the server won't be able to make duplex callbacks to the client?
1) If you want all clients to share the same server, you need to make your service a singleton. Add this attribute to the class implementing your service (not the interface):
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
That said, I suspect that what you really want is a synchronized, static (thread-shared) instance of a List<ServerClient>. Then you would iterate over that to send a message to each client. With that design, you wouldn't need a singleton server (just some good thread safety around the list).
2) If the clients close their server proxies, the server will not be able to send them any messages. You need to keep the proxy open and stash them somewhere in the client. This design will of course significantly limit scalability.
By default each client will get its own instance of the service. You can however make your service a singleton (which will than process requests from all client).
You may also want to skim through this Instance management article
I have a WCF service hosted in IIS and it is consumed by an ASP.NET application. Service and client are on diferent servers and communicate over internet.
Message security over wsHttpBinding is used as the security model (using X.509 certificate).
I tested the service with Fiddler and everything seems OK unless for a single call there are 4 sessions in fiddler (two round-trips). I don't need sessions with WCF and want my calling threads (which are asp.net worker threads), not to be blocked when calling a WCF method.
How can I achieve fire-and-forget pattern when using a WCF service (I can change the service contract if needed) ?
Fire and forget (One-Way operation) only says that your operation doesn't return any result and so client doesn't have to wait for server processing. But it has nothing to do with infrastracture calls you see in fiddler. First of all turn off estabilishSecurityContext and negotiateServiceCredentials in your security element (these are turned on by default) and try it again.
I assume that when you say "fire-and-forget" you are referring to a web service call that yields no return parameters. WCF has the notion of One-Way Method invocation that might help you here.