Azure documentation lacks and articles are often obsolete.
I've read that "Transient Fault Handling" (TFH) for Azure services (ServiceBus, FileStorage...) is now fully managed. It seems now there is nothing to implement on the client side. In the past, we could use Enterprise Library to manage such purposes but it is retired. For accessing SQL Database, a policy is implemented for Entity Framework (https://msdn.microsoft.com/en-us/data/dn456835.aspx).
Here are my questions :
Is it necessary to use Azure SDK on ServiceBus and FileStorage to benefit from policies that are now implemented on Azure ?
How is it possible to manage TFH when accessing data with something that is not EF ?
We need to ensure that our components (that use WebClient, raw ADO.NET...) will run correctly in a maintanable way.
I've read that "Transient Fault Handling" (TFH) for Azure services
(ServiceBus, FileStorage...) is now fully managed. It seems now there
is nothing to implement on the client side.
This is not correct. The service by itself will not handle transient errors. It is the responsibility of the client to handle transient errors. If you look at Storage Client Library (>= version 2.0), you will find retry policies there using which you can instruct your client code to handle transient errors.
Now coming to your questions:
Is it necessary to use Azure SDK on ServiceBus and FileStorage to
benefit from policies that are now implemented on Azure ?
It is certainly not necessary to use SDKs to handle transient errors but they make your job easier. SDKs come up with a variety of ways to handle transient errors (plus you could extend the functionality available in the SDK to come up with your own transient handling strategy). To elaborate, let's consider Storage Client library which is a wrapper over Azure Storage REST API. Now this library has defined which errors should be considered transient (HTTP Status Code 500+) and which errors should not be considered transient (HTTP Status Code 400 - 499). Furthermore it comes with different kinds of retry logic - Exponential (default), Linear, or None. As a developer, you can decide what retry logic should be used in case of a transient error and bake that into your code. If you were not using these SDKs, everything needs to be done by you starting from which errors should be considered transient and how the retry should be implemented. SDKs just make your job easier.
How is it possible to manage TFH when accessing data with something
that is not EF ?
If you're using ADO.Net and you get an exception, what you can do is take a look at the ErrorCode returned by the service and determine if the error is transient or not. For a list of SQL Error Codes, please see this link: https://azure.microsoft.com/en-in/documentation/articles/sql-database-develop-error-messages/. I would also highly recommend reading this article as well as to how you would go about implementing your own TFH: https://azure.microsoft.com/en-in/documentation/articles/sql-database-connectivity-issues/.
Related
I have looked through the sample code here here to understand how to handle connectivity issues with the azure relay. They use an exponential backoff mechanism in Microsoft.Practices.TransientFaultHandling to handle the recreation of a faulted connection:
retryStrategy = new ExponentialBackoff(100000, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(60),
TimeSpan.FromSeconds(1));
...
...
var shouldRetry = retryStrategy.GetShouldRetry();
if (shouldRetry(retryCount++, statusBehavior.LastError, out waitPeriod))
{
Thread.Sleep(waitPeriod);
Open();
Console.WriteLine("Relay Echo ServiceHost recreated ");
}
After more research, I noticed that according to the page on Microsoft.Practices.TransientFaultHandling:
This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.
Then, according to the link for transient fault handling, it states:
Important: Recent versions of SDKs for both Azure Storage and Azure Service Bus natively support retries. It is recommended to use these instead of the Transient Fault Handling Application Block
However, I don't see any examples anywhere on how to implement similar behavior to the sample, but using the Azure Service Bus SDK retry class(es) instead. What is the standard way to implement this? Or, is the quote above saying there are already built in retry mechanisms for the wcf connection, such that I don't need to worry about recreating my WebServiceHost and its corresponding connection(s)?
See: Retry guidance for specific services.
I'm answering this after trying a few different solutions, and I think the best way to do this currently would be to just use the more recently updated Microsoft Transient Fault Handling Library instead of the old deprecated Microsoft.Practices.TransientFaultHandling. This library has similar functionality to the deprecated one currently being used in the sample here here, and the rest of the solution offered for an exponential backoff can still work almost the same with this newer (although definitely not new) library. If Microsoft believes this is not the way to go in the future, hopefully they will update their azure relay samples to show a recommended solution, or solutions. Then, I could update this answer.
Given a simple high level architecture, e.g a cloud service with a web role, and a compute role, under what circumstances would we choose to use WCF as the communication method between the web role and the compute role, rather than service bus.
There is a lot of documentation, and examples regarding service bus, but I would like to understand if there are any platform benefits to using Service Bus, rather than WCF.
Given the calls are synchronous, and short, e.g a typical API call for getting data onto the website, would you choose WCF over queuing messages and replies onto a queue?
It would appear logically that for a synchronous call WCF would offer the least amount of overhead and latency?
I don't fully understand if the platform offers any "clever" tricks to keep the service bus operating as quickly as a TCP connection over WCF, (Given the queuing overhead?) and would like to understand this further.
At the moment if I was to pick an implementation for this type of call I would choose WCF, which maybe a little naive.
Just to clear, the calls always return data, they are not long running, or fire and forget.
Thanks!
I think it depends on what specifically you want to do.
Service Bus is typically used more for what I would call constant contact type interactions. It should be more performant, but more complex to set up. It also has bi-directional communication capabilities. So you get a lot of extra flexibility out of it.
I would swap WCF for the more modern Web Api. Both solve the same core problem primarily in serving up content. I think of it as just that an API, not necessarily a platform for message passing and handling. They solve 2 different core problems.
I would actually solve the likely problem differently and use Azure Websites + WebJobs. Its the same sort of thing. You can bind the WebJob to an Azure Queue, table or blob and put messages on that storage mechanism, which the job picks up and does something with. The web role I do not believe should rely on content coming back from the job. The job may hit a SignalR Hub that you have on the AzureWeb site post completion, which pushes state back down to the affected parties.
Reference Materials:
WebJobs: https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/
SignalR: http://signalr.net/
Azure Web Apps: https://azure.microsoft.com/en-us/services/app-service/web/
When we first migrated to Azure, transient fault handling via the Enterprise Application Block 5.0 was the best game in town. We use it to automatically perform retries when getting an Azure SQL Connection, accessing ASP.NET Session objects and accessing ASP.NET Application objects. To do so, we make use of the following classes respectively:
ReliableSqlConnection from the Application Block
Our own ReliableApplication class that extends Microsoft.ApplicationServer.Caching.DataCache by applying the Application Block cache RetryPolicy when accessing Application objects
Our own ReliableSession class that extends HttpContext.Current.Session by applying the Application Block cache RetryPolicy when accessing Session objects.
Now according to Microsoft's Transient Fault Handling Patterns and Practices as of March 2014:
Recent versions of SDKs for both Azure Storage and Azure Service Bus natively support retries. It is recommended to use these instead of the Transient Fault Handling Application Block
What Azure SDK classes should we use to replace our dependencies on deprecated Enterprise Application Block Transient Fault Handling?
Please follow the following blog posts to implement retry logic(These are ADO.NET samples but you can replicate the logic in the language of your choice)
https://msdn.microsoft.com/library/azure/ee336243.aspx
https://msdn.microsoft.com/en-us/library/azure/dn961167.aspx
The first one is implementing retry logic using the Enterprise Library and the second one shows you how to implement retry logic using custom code.
To answer your question :
What Azure SDK classes should we use to replace our dependencies on deprecated Enterprise Application Block Transient Fault Handling?
You will have to use retry logic to improve connection resiliency. Unfortunately there is no Azure SDK that you can use currently to implement retry logic to connect to Azure SQL DB.
Let me know if this makes sense.
Best,
Meet Bhagdev
Program Manager, Microsoft
This site has examples for the native client support for each service
https://github.com/mspnp/azure-guidance/blob/master/Retry-Service-Specific.md
Background
I'm troubleshooting some issues with a .NET Web API 2 service. The issues are inconsistent, and from the requesting service, all we see are Connection Resets and Socket Exceptions. It is not even hitting the User Code/logging in the API, but for low level exceptions that doesn't rule the WEB API out as the culprit.
Research
A very useful tool in the past for troubleshooting similar issues in WCF was enabling WCF Tracing. I'm looking for an equivalent that can show the low level Service Trace for the Web API.
I've found Global Error Handling and I've used packages like Elmah in the past. but to my knowledge this only shows unhandled exceptions, as opposed to the entire trace of the Service like the svclog does.
I also know about Fiddler and Wireshark, and while these are excellent tools for http tracking and low level protocol sniffing. At this point, I'm interested more in what the .NET service thinks it's receiving and how it's processing those actions, rather than if packets are making it over the wire.
Summary
Is there an equivalent for Web API 2 to WCF .svclog? With particular focus on the low level service interactions with bytes/requests.
Edit
I have accepted the best answer, both answers pointed to the same form of tracing. It's worth mentioning, that for this specific issue the tracing did not show any additional information, however I do believe it is the closest tracing Web API has to WCF svclog.
There is no direct equivalent solution in WebAPI but they have added some tracing capabilities in V2. You can refer to the article below.
Tracing in ASP.NET Web API 2
If you have connection issues, I would also check the IIS logs and the httperr logs that may give you more details on such issues.
WCF and WebAPI are night and day different. WCF has a complex messaging infrastructure, with lots of middleware that requires the level of tracing they supply to troubleshoot.
WebAPI on the other hand is quite simple, and there is very little that sits between the request itself and your code. Any problem in that code presents itself as YSOD (ie a 500 error, which if custom errors are disabled will show the exception). Just like an MVC or even standard ASP.NET application.
Now, there is some tracing available, but it is not to svclog's like with WCF. There is information here:
http://blogs.msdn.com/b/roncain/archive/2012/04/12/tracing-in-asp-net-web-api.aspx
You will have to write your own logger, although maybe there are some loggers out there you can find already.
I'm trying to create a feedback system which all messages get posted to then published back to the correct subsystem. We are using queues quiet heavily and i want to make the subscriber code as clean as possible. I want to switch based off the message id i get into the feedback system and publish to its specific subscriber. i don't want to make a service for each subscriber to listen for messages.. i was thinking i could set up a queue for each subscriber and trigger to invoke a com+ component.. but i'm looking for a more modern way..
I was looking into NServiceBus but it seems i'd need to make a service/executable/webservice for each listening system ( its a little less work to make a C# dll and invoke a method) and i'm not sure if NServiceBus can handle dynamic endpoints based off a preloaded config ( loaded from a db ). WCF is also a choice.. it can handle dynamic endpoints for sure..
what do you think is the best solution for the lease amount of code/ scalable for new systems to subscribe?
Thanks
In case you are ok with online solutions you could take a look at the latest .NET Services SDK for Windows Azure which has queue service bus http://www.microsoft.com/azure/netservices.mspx It relies on WCF messages and supports routing etc. Some blog posts about this here http://vasters.com/clemensv/default.aspx
Another framework you could try is MassTransit http://code.google.com/p/masstransit/
It seems you're looking for a service host, rather than a message broker. If so, Microsoft's recommended way is to host your WCF services in IIS. They can still use MSMQ as transport, but the services themselves will be managed by IIS. IIS has evolved significantly since its early days as HTTP server, now it's closer to an application server, with its choice of transports (TCP, MSMQ, HTTP), pooling, activation, lifetime policies etc.
Although I find WCF+MSMQ+IIS somewhat overcomplicated this is the price you pay to play on the Microsoft field.
For nice and simple message broker, you can use Active MQ instead of MSMQ, it will give you message brokering as well as pub/sub. It's quite easy to work with in .NET, check this link out: http://activemq.apache.org/nms/