0 Comments

Using the NServiceBus distributor and few workers doesn’t change things  when in-order message processing is considered:  If the client sends the messages in a batch, they are processed in-order. All the messages in one batch are processed by one of the workers and only by using one thread.

Here’s a screenshot from our distributor sample application when the client calls Bus.Send for each message using the “Register users” –link (messages are not batched):

distributor1

Like discussed previously, ##### represents a handled ChangeUserEmailAddressCommand-message and ***** represents the handled CreateUserCommand-messages. We would like the CreateUserCommand-message to be processed before the ChangeUserEmailAddressCommand-message. In our first example this is not happening.

The picture is completely different when the two messages are sent in a batch:

distributor2

As you can see, the distributor disposes the messages to the workers in the same batches as they were sent by the client.

When the worker2 is configured to have more than one thread (by changing the NumberOfWorkerThreads), output is again substantially different:

distributor3

Even though the output is different, the end result is same: The messages are processed in the right order.

Benefits

If your server’s workload is getting too high, it’s reasonable easy to to plug in the NServiceBus distributor and all the required workers.  You can do this without changing anything on the client’s side. This allows you to scale-out your system when needed.

0 Comments

The NServiceBus Distributor sample application has been updated. You can get the latest version from GitHub. 

Some users reported that they had to modify the projects’ settings (“Start external program” to be specific) before running the app . This was because the source control didn’t include the user-project files. They have now been added, making the sample application truly a “download and run” example.

Changes:

  • Added the .user –project files.
  • Updated the NServiceBus to a newer version (2.1). This is to allow the distributor’s logging level to be set through profiles. This wasn’t possible with the 2.0 version.
  • Distributor is run with NServiceBus.Integration profile by default.

0 Comments

distributor3

Here’s a new NServiceBus sample application, this time showing the use of NServiceBus distributor. The application is built so that you can just grab the source code, open the solution and run it.

The sample application is built with Visual Studio 2010 and .NET Framework 4.

Background

We’ve covered the distributor’s basics before (“Using NServiceBus Distributor”)and this sample uses the configuration files from that post. The sample is built over the application which we created in “NServiceBus: In-order message processing “.This means that the application has an ASP.NET MVC 2 client.

Project structure

The sample application’s solution contains five projects:

  • Client
  • Distributor
  • Messages
  • Worker
  • Worker2

The projects are configured to start the generic host automatically, so when run, four windows should open: three console windows (one for every generic host) and one browser window with the client. This works if you open the solution by double clicking it. This sets the Visual Studio’s working folder to the solution’s root.

Troubleshooting

If you have problems running the distributor or the workers, change the “Start external program” from your project’s configuration to point into the correct NServiceBus.Host.exe.

Please let me know if you encounter any other problems.

Download

You can get the source code from GitHub.

0 Comments

Welcome to the first ever NServiceBus Weekly. As the name suggests, these posts will concentrate on the latest happenings around the NServiceBus. New post is released once a week, every Wednesday.

There’s going to be few different sections:

Every section will concentrate on NServiceBus. Also, any feedback is greatly appreciated. Please let me know if I missed an interesting link.

Because this is the first NServiceBus Weekly, we have an extra section: NServiceBus. This section will contain links to articles and web pages which will give you a good introduction on this popular open source service bus for .NET Framework, founded by Udi Dahan.. Also this week’s NServiceBus Weekly will contain links which are older than one week. Starting from the next post, I will concentrate on the latest happenings.

NServiceBus

  • NServiceBus homepage – This is the home of NServiceBus. It contains documentation, download links and license information. Start from here.
  • NServiceBus official documentation – Unlike some other open source projects, NServiceBus actually has a pretty good documentation. The FAQ on there front page will get you started quickly.
  • NServiceBus source code – Even though GitHub isn’t the official place for NServiceBus source code, it’s the easies way to get the latest codes.
  • NServceBus samples – NServiceBus source code contains a large number of sample applications. Pub/sub, logging, ASP.NET communication, WCF integration and so on, they all are covered in the sample applications.
  • NServiceBus discussion board  – NServiceBus Yahoo! group is the main source of NServiceBus related discussions. You can use Yahoo’s own web page or Grouply to follow the discussion.
  • Enterprise service bus – NServiceBus is an enterprise service bus. This Wikipedia article will give you a good introduction on the topic.

News

  • "Still OSS, but higher value offerings not free in binary form." – NServiceBus has taken the next step: It now offers a commercial option. The NServiceBus source code will continue to be open and anybody can still fork the code. The commercial version will offer more features like distributor, gateway and saga timeout management.  This change was made “In order to save #NServiceBus from the same fate as other OSS projects (victims of their success)”. The current 2.0 version will remain completely free. The next service pack of 2.0 version will be called 2.5.
  • NServiceBus License Packages – If you’re interested in the features provided by the commercial licenses, this page will give you all the details.
  • NServiceBus Developer Studio – Not much is known about the up-coming NServiceBus Developer Studio. Currently it seems that it will be a commercial application and it will allow the developers to visualize what is happening inside the NServiceBus. More news to follow, I’m sure.

Tutorials and Articles

Community

Here’s also an list of blogs which have been active lately and have posts related to NServiceBus. Please let me know if I missed something.

Got an interesting NServiceBus related link? Did I miss something? Link not working? Please, send mail or contact @MikaelKoskinen.

1 Comments

NServiceBus is like all the other messaging systems: It doesn’t promise to process the messages in-order. This attribute must be kept in mind when designing your application around a message bus. Let’s examine a situation where we have an ASP.NET MVC application with a user registration form. When the user fills the form, the controller can send one or many messages into the bus, depending on what information user has entered. For simplicity’s sake our example will have two different messages: CreateUserCommand and ChangeUserEmailAddressCommand.

Problem description

If our client sends a CreateUserCommand-message followed by a ChangeUserEmailAddressCommand-message and our message bus doesn’t promise to process them in order, how can we be sure that the ChangeUserEmailAddressCommand isn’t processed first? How can we update the user’s email address if the user isn’t in our database yet?

This tutorial uses NServiceBus 2 RTM and ASP.NET MVC 2. There’s a link to the source code at the bottom of this post.

Message handlers

Throughout this tutorial we are using the following message handlers at our server side:

   1: public class ChangeUserEmailAddressCommandHandler : IHandleMessages<ChangeUserEmailAddressCommand>
   2: {
   3:     public void Handle(ChangeUserEmailAddressCommand message)
   4:     {
   5:         Thread.Sleep(100);
   6:         Console.WriteLine("###########{0}", message.UserId);
   7:     }
   8: }

and

   1: public class CreateUserCommandHandler : IHandleMessages<CreateUserCommand>
   2: {
   3:     public void Handle(CreateUserCommand message)
   4:     {
   5:         Thread.Sleep(300);
   6:         Console.WriteLine("***********{0}", message.UserId);
   7:     }
   8: }

Creating a new user is a more robust operation so it takes a little longer than changing the user’s email address.

Client’s controller

To simulate the stress for our server, our client will send it 100 messages in total, divided in half between the CreateUserCommand- and ChangeUserEmailAddressCommand-messages. The initial code in ASP.NET MVC controller looks like the following:

   1: public ActionResult SendMessages()
   2: {
   3:     for (int i = 0; i < 50; i++)
   4:     {
   5:         var createUserMessage = new CreateUserCommand() { UserId = i };
   6:         MvcApplication.Bus.Send(createUserMessage);
   7:
   8:         var changeEmailMessage = new ChangeUserEmailAddressCommand() {UserId = i};
   9:         MvcApplication.Bus.Send(changeEmailMessage);
  10:     }
  11:
  12:     return View("Index");
  13: }

Pretty simple. We first send a CreateUserCommand-message and then a ChangeUserEmailAddressCommand-message. Both messages have the same user id.

Server’s configuration

This is how our server’s configuration looks like:

<MsmqTransportConfig

InputQueue=<span style="color: #006080">"InputQueue"</span>

ErrorQueue=<span style="color: #006080">"error"</span>

NumberOfWorkerThreads=<span style="color: #006080">"1"</span>

MaxRetries=<span style="color: #006080">"5"</span>

/>

First test

Given the previously described controller, message handlers and the server configuration will give us the following result (copied from server’s console):

inorder

Keeping in mind that the lines with ****** represent a CreateUserCommandHandler and the lines with ###### are caused by a ChangeUserEmailAddressCommandHandler, we can see that the messages have been processed in order. Did we get lucky? No. Remember our server’s configuration? In our first test the server is using only one thread (NumberOfWorkerThreads) to process all the messages. Because of this, the NServiceBus handles them in order.

Second test

Our server has a nice quad core processor so we’re wasting it's computing power by limiting it to only one thread. So, for our second test, let’s modify the NumberOfWorkerThreads to 4. Here are the new results:

outoforder2

We have a problem. Our server is trying to change the email address of the user 48 before it has been created in our system. The likely outcome? Exceptions. Because the NServiceBus has now more worker threads, each thread will process a new message from the queue as soon as it has handled the last one. Is there an easy way to make sure that the required messages are processed in-order? Yes, if we can change the client’s code.

Sending messages in-order

Our client’s controller sends the messages one after another, for a total count of 100 calls to Bus.Send. But the Send-method also has an overload which takes an array of IMessages as a parameter.  By putting the two relevant messages in an array, in the correct order, we can be sure that the NServiceBus will process them in order. The messages sent in an array will be processed by one thread by the server.

Third test

Here’s our new client code:

   1: public ActionResult SendMessagesInOrder()
   2: {
   3:     for (int i = 0; i < 50; i++)
   4:     {
   5:         var createUserMessage = new CreateUserCommand() { UserId = i };
   6:         var changeEmailMessage = new ChangeUserEmailAddressCommand() { UserId = i };
   7:
   8:         MvcApplication.Bus.Send(new IMessage[] {createUserMessage, changeEmailMessage});
   9:     }
  10:
  11:     return View("Index");
  12: }

This time the two messages are packed in an array (a batch) and the Bus.Send is called only 50 times. The results are interesting:

inorder2

NServiceBus makes sure that the ChangeUserEmailAddressCommand-message is always handled after the CreateUserCommand-message. Fixing our problem was rather easy because we we’re able to change our client’s code. But what can we do if we can’t alter the client?

Other option

One of the easiest solution is to change our ChangeUserEmailAddressCommand to call Bus.HandleCurrentMessageLater-method if the user isn’t in our system yet. This will send the original message back to the input queue. Because it ends up as the last message in the queue, it’s highly probable that the system has been able to process the relevant CreateUserCommand-message before the message is processed the second time. But make sure to create a failure system so that the same message doesn’t end up in an endless loop. At some point it has to be moved into an error queue.

Conclusion

NServiceBus doesn’t handle messages in-order. It’s up to the developer to make sure that the relevant messages are handler in the right order. The easiest way to do this is to send messages as batches from the client.

Download

You can get a sample application from the GitHub.