My buddy Victor asked me the other day about the relationship between IIS and the BizTalk databases. That is, if we restart the SQL Server service or server, what happens to messages that are still submitted to the BizTalk web services on an active IIS server?
So, I put together a really quick application where I tested four scenarios: downstream host unavailable, IIS unavailable, receive location offline, and SQL Server unavailable.
Also, to legitimately gauge service behavior, I exposed both classic ASMX services and WCF services for my BizTalk application. Both services were built as one-way HTTP services hosted in IIS. The published data is then routed to a single FILE send port via message-type routing.
Scenario: Processing Host is Unavailable
For this scenario, I simply disabled the in-process host that runs the send port subscribing to messages published by the services.
Result: Messages are published with no problem, and everything is queued up until the in-process host comes online. No message loss and no errors to the service callers.
Scenario: IIS is Unavailable
Here I turned off the IIS website hosting the services.
Result: As expected, both the ASMX and WCF services returned errors to the client application. The ASMX service returned an error saying:
error: System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:80
The WCF service returned the following error:
error: System.ServiceModel.EndpointNotFoundException: Could not connect to http://myserver/Blog.Biztalk.AvailabilityTestWCF/ContractService.svc. TCP error code 10061: No connection could be made because the target machine actively refused it 192.168.131.65:80. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 192.168.131.65:80
So the client gets an error, no message is submitted to BizTalk by either service, and the client will be expected to try again later.
Scenario: Receive Location is Offline
Now I’ve turned off the actual receive locations. The website is up and running, but the BizTalk receive locations aren’t listening for the inbound messages.
Result: The ASMX service returns a success message (HTTP 202), even though no message is published to BizTalk. There is an error in the System Event log stating:
The Messaging Engine could not find the receive location for URI:”/Blog.Biztalk.AvailabilityTest/ContractService.asmx”.\
Please verify the receive location exists and is enabled.
However, the client does NOT get an error even though no message was published (or suspended) by BizTalk.
The WCF service returns an HTTP error and the following message to the client:
error: System.ServiceModel.ServiceActivationException: The requested service, ‘http://myserver/Blog.Biztalk.AvailabilityTestWCF/ContractService.svc’ could not be activated. See the server’s diagnostic trace logs for more information.
In this case again, no message is published, BUT, at least the client knows that a problem occurred. Much better than the ASMX behavior.
Scenario: SQL Server is Offline
In this case, I’ve shut down the SQL Server service and the in-process hosts that are running.
Result: The ASMX service continued to return HTTP success messages, even though it could not publish to the MessageBox. The IsolatedHost (which runs the Message Agent) can’t connect, but the client isn’t told this.
The WCF service, however, returns the same error it did on the previous scenario. So it did not publish the message either, but, again, it returned a proper exception to the client.
Looking at the IIS logs, I wanted to confirm the service response. For the ASMX service call when the database was offline, I can see the following entry:
POST /Blog.Biztalk.AvailabilityTest/ContractService.asmx – 80 – 127.0.0.1 202 0 0
Notice the HTTP 202 returned to the client. The next entry in the log file represents my call to the WCF service while the database was still down:
POST /Blog.Biztalk.AvailabilityTestWCF/ContractService.svc – 80 – 192.168.131.65 – 500 0 0
Notice the HTTP 500 error which represents an internal server error returned to the caller.
So, we can conclude that ASMX services do a lousy job of reporting what actually happens after it tries to publish messages to the BizTalk bus. Unless the IIS server is explicitly taken down during database server maintenance or restarts, you run the real risk of losing messages without the client being aware of it. For WCF services, we see much better handling of message publishing problems. This is probably due to the fact that the BizTalk WCF service host relies heavily on the BizTalk configuration database and receive location availability to complete its operations. While it still can’t save the inbound requests, it at least tells the caller that something went wrong.
Anyone else have different experiences than the ones I demonstrated above?