How will I be able to count the number of exceptions thrown during the execution of a service?
Right now I'm using behaviors to hook with the dispatchers using IOperationInvoker and IParameterInspector. But I need to know how can i count the faults and exceptions that occurs in a particular operation or the total occurrence in the whole service.
A couple of approaches exist. You can use tracing (and inspect your log files); through instrumentation, that is, use performance counters to monitor faults on services or operations.
A nice way of achieving service monitoring is also available through AppFabric, if this is available to you.
HTH
Related
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
WCF API Deployment Versioning
I am working on WCF Rest services. I have several services.
Now, before a client hits a service, I want to add a check viz. a version number.
If the version number is less than, suppose 2.0, then client application should get an error "Application is outdated" and it should not hit the service.
My main purpose is, I dont want to apply this check in each webservice. I want some generic service which would first check the version and then only allow the client to hit the desired service.
How can this be done.
Also, whether this is possible in classic Webservices in .NET.
I think this is a pretty bad idea - you would need to create a centralised service which somehow knew all the version details of all your service endpoints, and then require your consumers to make an extra call in order to consume your services.
This creates a single point of failure in that if the "Version Checker" service is unavailable then "valid" consumers (ones with the correct client version) will still be unable to call your services.
Also you would need to maintain the current version of each of your services in this central location, which generates support overhead.
The best way of versionning your services is to try to make non-breaking changes so that older versions of the clients can be supported. You an do this in many ways. I have posted about this before here and here.
If you must make breaking changes then you either need to let your consumers break (and therefore be forced to upgrade) or you co-host different versions of your services at different endpoints.
NOTE: There is something which is kind of designed for what you are thinking of, called UDDI. The idea behind a UDDI server is it can store all the information about your services, including endpoint address, transport and even your exposed types, so that consumers can query the UDDI at runtime and assemble a client on-the-fly.
This would result that your consumers need to have absolutely no knowledge of your service version at all, and would retrieve this information at runtime from UDDI.
However UDDI is rarely used (probably for the same reason that it introduces a single point of failure). I have used it exactly once in my career when I built an ESB for a client.
EDIT
In response to your comment, I think the best solution for you would be to expose a Version member on your service operation request contract type which would require consumers to declare which version of the service they are expecting to call.
When the request is received, you can interrogate the request and check the version. If they don't match then you can throw an exception of a type you have defined in a FaultContract. (more about fault contracts here).
This will enable your consumers to wrap the service operation call in a catch block and handle the custom exception type passed back. I don't think there are any built in exceptions which cover "invalid version" errors so you will need to define your own.
This means that consumers will only get an exception back when they try to call your service with an outdated version attribute and avoids having to make an extra service call. Also it distributes this information rather than centralising it (which is more robust approach).
EDIT 2
In response to your comments, Fault contracts are not supported in asmx. You will have to throw the exception on the service and then on the client catch the exception as a SoapException. On the client you then have to interrogate the SoapException message (not nice) in order to work out if it's because of versionning.
What is a best practice for designing WCF services concerning to the use of more or less operations under a single service.
Taking into consideration that a Service must be generic and Business oriented, I have encountered some SOAP services # work that have too much XML elements per operation in their contracts and too many operations in a single service.
From my point of view, without testing, I think the number of operations within a service will not have any impact on the performance in the middleware since a response is build specifically for each operation containing only the XML elements concerning that operation.
Or are there any issues for having too many operations within a SOAP service ?
There is an issue, and that is when trying to do a metadata exchange or a proxy creation against a service with many methods (probably in the thousands). Since it will be trying to do the entire thing at once, it could timeout, or even hit an OutOfMemory exception.
Dont hink it will impact performance much but important thing is methods must be logically grouped in different service. Service with large number of method usually mean they are not logically factored.
I have one Operation on a wcf service which can be executed by only one request at the time.
I can easily achieve it using the Single concurrency mode, anyway other operations on the service can be executed simultaneously and, more important, I wouldn't like my client to wait for the timeout exception, but I would like to throw a specific exception.
Which is the best way to implement it? Should I use a static object to lock the critical section? Any other techniques?
I'm working on shipping in a change for my lab that will hopefully help diagnose some weird channel-faulting weirdness we're seeing. There's a test application that uses DuplexChannelFactory to connect to a couple windows services, and for some reason the channels on this test application seem to be faulting quite a bit. I have plans to implement some retry logic in there, but it would be great to figure out why exactly they're faulting.
I know that channel factories and proxy objects all implement a lot of interfaces, and I've used reflector to crawl through some of them, but I haven't found anything like what I'm looking for. Is there a way to query these objects after they've faulted in order to get some information about what caused the fault?
Edit: The configuration is very basic--the binding is just the default-constructed NetTcpBinding, the service implementation has [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)], and no special attributes are on any of the operations in the service contract. However, I'm asking more about general techniques in diagnosing channel faults, not diagnosing this specific case. I wouldn't expect configuration specifics to have too much impact on that; if anything, the configuration details would be something returned by said diagnostics, right?
Ladislav and Shiraz answers are all good and I have gave them +1.
All I can add to them is that normally a faulted channel is the result of unhandled exception on the server. When that happens, WCF thinks that there is somethig fundamentally wrong with the server and faults the channel so that it cannot be used.
The correct approach - which I believe should have been default and come for free - is for the service to catch the exception and create a FaultException and return it (look at this form example http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx)
The reason WCF does not make as default is that it changes the contract and the WSDL so the client has to get the updated WSDL.
So if I were you, I would catch the exceptions, log them and then return a fault exception and this way I would know what the problem is and channels are not faulted.
First thing is it this test application, or are the specific services used by other clients.
Assuming that it is the test client that is causing the problem. There could be 2 problems:
Not closing proxies, therefore hitting max connections to the server.
Not aborting proxies when they are in a failed state.
Diagnostic tool you are looking for is called WCF Tracing. It usually shows why the channel has faulted. You can configure it on both client and server and use SvcTraceViewer.exe to browse collected traces.
Have you hooked on to the ICommunicationObject.OnFauled
I have the standard error handing in place in my service:
I have an IErrorHandler hooked to the service to handle unexpected errors during service execution.
I have try/catch blocks in all my service methods to handle expected cases.
However, there are cases where exceptions are thrown on the server and neither is called.
Here is a case where the server exception is not sent to the IErrorHandler:
Set the receiveTimout on the server binding to 5 seconds.
On the client do this:
.
Service1Client sc = new Service1Client();
ICommunicationObject o = sc as ICommunicationObject;
o.Open(); // open channel
sc.GetData(10); // do a first call
Thread.Sleep(10000); // wait longer than the server receiveTimeout
sc.GetData(10); // Attempt another call: server throws a FaulException
In that case, the error is thrown on the server but I cannot find a way to handle it (and log it). I know an error is raised because if I attach a debugger on the server process and break on all exceptions, the debugger breaks.
I have found other similar cases where low level errors are not passed to my program.
Where can I hook my code to ensure that I can handle ALL exceptions that occur on the server before they are returned to the client app? Should I implement my own IChannel or some other low level interface?
Thanks
UPDATE Sep 21 2009: See this thread on the Microsoft WCF Forum. I'll probably have to implement my own Channel if I want to handle this type of exception. I'll update this post again when I have more info.
After much research and experimentation, the answer is:
At this time (.Net 3.5) there is no mechanism that allows one to handle all possible exceptions that may occur in the context of a WCF call.
Exceptions that happen during the service method execution can easily be handled with:
Try/catch blocks in all service methods to handle expected cases.
IErrorHandler hooked to the services to handle unexpected errors during service execution.
However, for low level WCF infrastructure errors, there is no perfect solution. The best solution that exists seems to be to implement a custom channel to catch more exceptions.
In this Microsoft Connect Bug Report, Microsoft confirms that there is no way to handle all types WCF infrastructure errors.
In this thread on the Microsoft WCF forums, there is a sample on how to implement a custom channel. That solution only works for HTTP, not for HTTPS. Also some WCF infrastructure errors are not caught by the custom channel either (see more details in that specific thread).
Use FaultContracts. Then the fault can be handled at the client end.
http://msdn.microsoft.com/en-us/library/ms732013.aspx
http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx
This is also much better for debugging, since often you will be developing a client and don't want to bring down the server for debugging purposes.
On the client end, use try/catch blocks to catch all exceptions/faults. There are definitely errors that can't be detected on the server end, such as a communication problem, so you need to handle errors on the client end anyways.
If you want centralized error handling, you can create a service that takes messages about all errors, send the error to that server, and have it log that. This can be useful if you want to create a centralized message tracing/performance analysis/logging tool and have a large number of application processors, servers, clients etc.
The point is - if the server is not reachable or can't handle the message, there won't be an error on the server - the error will pop up on the client ("TimeoutException" or others).
So in those cases, having the IErrorHandler on the server really isn't gonna help - since the error really happens on the client (no connection can be made, due to network down, or typo in server's address or sstuff like that).
So on the client side, you definitely also have to use try....catch around all your server calls.
Marc
Set up diagnostic tracing and check the logs with Service Trace Viewer Tool. Link contains information about configuring tracing as well.