I'm working on a WCF service where I created a custom UserNamePasswordValidator to validate the client. If username or password are wrong a FaultException is thrown.
I use nServiceBus 5 in the WCF service to send the client message to some internal systems.
The issue is that if a FaultException is thrown because the client hasn't access to the service, the client's request is processed anyway because (I guess) nServiceBus is handling the exception also if I'm not inside an handler.
The bus is started inside a custom ServiceHostFactory.
How could I tell to nServiceBus to don't handle that kind of Exception?
Related
I have implemented message layer security using message inspector mechanism in a wcf service.
On the client side, in IClientMessageInspector.BeforeSendRequest I add an authentication header.
On the service side, in IDispatchMessageInspector.AfterReceiveRequest I inspect the authentication header in the message. If it is not found or as expected, I throw a SecurityException and try to log it to a database.
Here comes the interesting part. When logging to database, I try to read from this webservice again (this is web service which provides configuration info).
This is where the service stalls/deadlocks. I can see that the call to read configuration (when logging to db) is made, but I don't receive the call on the service. I keep getting a timedout exception every time.
After a little googling, I came across this post, which mentions that message inspectors are synchronous in nature. If that is so, how can I achieve what I am after?
Is there a way to get a WCF service which needs to maintain backward compatibility with asmx clients to serialize exceptions as SoapExceptions rather than FaultException or FaultException?
I have some service clients that cannot be upgraded, but we're standardizing all our services to WCF... We've got the services to mimic the asmx soap/xml format, but I can't figure out how to alter WCF's fault behaviour.
WCF does not generate either SoapException or FaultException. It generates SOAP faults. The client may translate the faults into SoapException or FaultException.
If the client is an old-style ASMX client, then it will throw a SoapException when it receives a fault. A WCF client will throw a FaultException when it receives the fault.
The bottom line is that you shouldn't have to change anything.
I am using the Wcf Routing Service with the netTcpBinding
I have a WCF Service named ServiceTwo exposing just only one netTcpBinding endpoint
I have a client application consuming the ServiceTwo
Then I have a routingService between them, the routing service has two endpoints, a basicHttpBinding and a netTcpBinding. The routing always use netTcpBinding to communicate with the ServerTwo.
I am using the full IIS 8.5, enabled Http Activation and Non Http Activation, already setup protocol "http, net.tcp" for the ServiceTwo and the routing service as well.
for these below scenarios, it works
if the client application client consumes the ServiceTwo directly, not go through the routing, using netTcpBinding -> it works fine
or the client application call the ServiceTwo through the routing using basicHttpBinding (the routing always use netTcpBinding to communicate with the ServerTwo) -> it also works fine.
But for the case client app using the netTcpBinding to connect to the routing (the routing always use netTcpBinding to communicate with the ServerTwo)
I just got an exception as below:
An unhandled exception of type
System.ServiceModel.CommunicationException' occurred in mscorlib.dll
Additional information: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.9659874'.
Could you please advise something I might miss and cause the error
Thank you very much.
Regards
This error occured for me, when my client was using SecurityMode.None, but not my Service. But I think the exception is rather general.
So I would advice you to re-check all values that set up your ServiceChannel incl. your Binding on Service & Client.
btw: this error occurs for me only in case the client sets a SecurityMode and the service does not! If it is vice-versa a more meaningful exception occurs. Namely: (ProtocolException - This could be due to mismatched bindings (for example security enabled on the client and not on the server))
I have created a wcf service with NetMsmq binding. And the operations are one way.
I wanted to handle the fault exception. However i found that the channel is not going to fault even after the exception is raised at the server side.
Can anybody tell me in what cases the wcf service will goes to fault state(provided while using NetMsmqBinding).
I am working on a prototype using WCF 4 routing services to create a pass through router, leveraging the error handling functionality
I have a requirement where if a WCF service generates a custom exception (in this scenario it is called a notPrimaryException), it should be handled in the same way as a communication exception is handled in WCF4 routing services error handling, that is, the message should be resent to the endpoints in the backup list.
Now I understand that this custom exception is returned from the service to the router as a fault exception at the message layer as opposed to a communication exception being returned at the transport layer.
I have tried using message inspectors and the IErrorHandler interface (ProvideFault and Handle Error) to identify if the notPrimaryException is occurring at the router but nothing is being picked up until it returns to the client as an unhandled fault exception. I was hoping to intercept this fault somewhere on the router and resend the message accordingly but I don't know if there are any appropriate behaviors.
Is there a way to shoehorn additional exception/fault types into the error handling infrastructure or is there another approach I may have overlooked?
Thanks and Regards,
Ivan
You should not be handling application errors on the router. Generally, the application developer has placed FaultExceptions on the service with the expectation of being able to handle them on the client.
If the FaultException is not received by the client, how does the client know what/anything went wrong?
The only errors you should be handling on the router are transport layer exceptions, application exceptions should be handled in the application.