Skip to main content

Event Hub and Service Bus - More useful exception information

Usually I don’t write posts about this kind of things, but last week I saw an update that makes our life better, especially if we are working with Service Bus or Event Hub.
If you had the opportunity to work with one of this messaging/event system and when to production with them, I’m pretty sure (99.99%) that you had at least one exception from the messaging system that was very vague.
A large system is not using only one Topic or Queue from Service Bus. But in the logs you can end up easily with a super duper generic exception, where you might not have all information about namespace, resource and so on. Because of this you start to write in the logs information from the ‘connection’ class to be able to log all the information that are needed.
Once you get an exception from Service Bus, you usually check the status of the service, look inside the code and try to find our what is the root problem. Sometimes you find the problem and you are able to fix it.
I’m happy in the moment when I’m able to reproduce the issue. In that moment I know that I understood the context and I’ll be able to fix the problem. But not all the time we can find the problem. It’s starting to be like voodoo, sometimes our code works, sometimes we get an exception, without being able to isolate the problem.
In this situations, we go on Azure Portal and open a support ticket, where we need to specify the exception that we had. Once we done this, we will get a reply from the support team that we forgot to specify the namespace and the resource name (topic, queue, event hub, subscription, consumer group, …). We go back to our logs, get this data and send them back.

As we can see, the exceptions that are throw by this service doesn’t contains enough information to be able to track the exception and the source of the error.
Because of this we had to write in the logs additional information and to provide to the support team not only the exception, but also other information about the service. Even if based on the Tracking ID it might be possible to find the exception. This happens not because it is not possible, but imagine to try to search for an ID in storages that are not only big, but also are in a format optimize for storing and persistence with minimal costs and not for searching.

The good news is coming from Service Bus team, that enhanced the current exception message. Starting from now, we will not see only the tracking and timestamp with the exception message, but additional with them information related to namespace and resource name will be in the message exception.
This information is useful, not only for Azure support team, but also for us, making our life easier. Additional to this, there is an URL to a page that provide us more information about this error and how we can fix it. I hope that this URL will be useful, because all the time when I had exception that point also to an URL, the URL was not valid or I was not able to find the information that I looking for – I hope that URLs for Service Bus will be useful.

In conclusion let’s take a look on how an exception looks like.

EventHub: EventHub(rvEventHub)/32
 The service was unable to process the request; 
please retry the operation. For more information on 
exception types and proper exception handling, 
please refer to
?LinkId=761101 Reference:bcac366a-adef-23fb-a342 
027f9aw84442, TrackingId:a5e1ab540423560f10001a4b
e4368a43a_G5_B1, SystemTracker:rvEHTest:eventhub: 
rvEventHub~10823, Timestamp:6/20/2016 08:43:46 AM


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…