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 http://go.microsoft.com/fwlink/
?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

Comments

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

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 http://go.microsoft.com/fwlink/?LinkId=260882 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 …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…