Skip to main content

Windows Azure Service Bus - Control what actions can be made

Did you ever need or want to disable the send functionality from a queue or from a topic? All the people start to send messages to you even if you say STOP. How nice would be to be able to say STOP.
We have good news for people that use Windows Azure Service Bus (Queue, Topics and Subscriptions). With the new version of SDK (2.0), we can control the operation that can be made on Service Bus. How nice is that.
People would ask – why we would want to do something like this. Well, there are times, especially when we make tests, when we want to control this. I see this value in two situations:
When we want to make performance tests, to see how many messages we can consume from a queue in a specific time interval
When there a lot of messages in the queue or topic and we don’t want to accept new messages anymore.
This feature can be controlled from the description of the queue, topic or subscription.  Based on what kind of service we use from Service Bus we can have different status. It is important to not forger to call the UpdateQueue or UpdateTopic/UpdateSubscription after you change the service status.
The entity status of a services can have the following values:
  • EntityStatus.Disable – Sending and receiving messages is disabled
  • EntityStatus.SendDisabled – Sending is disable
  • EntityStatus.ReceiveDisabled – Receiving is disabled
  • EntityStatus.Active – Sending and receiving are active
Don’t try to use a combination of this status. All the possible combinations are supported with this 4 status.
TopicDescription topic = namespaceManager.GetTopic("fooTopic");
topic.Status = EntityStatus.SendDisabled; //can continue to de-queue
This configuration can be made from the moment when you create the topic.
if (!namespaceManager.TopicExists("fooTopic"))
    TopicDescription topic = new TopicDescription("fooTopic");
    topic.Status = EntityStatus.SendDisabled; //can continue to de-queue


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…