We’ve seen before how the NServiceBus distributor can delegate the messages to its workers. But here’s couple interesting questions:
- Can the worker reply back to the client?
- Doesn’t the distributor become a bottleneck if it has to deliver the messages from the client to the workers and back?
And here are the answers: Yes. Not so much.
1. How to reply from a worker to the client when NServiceBus distributor is in use?
You can reply to the client using the basic Bus.Return and Bus.Reply-messages. It doesn’t matter that the distributor is used because NServiceBus will route the reply to the correct place.
2. Why doesn’t the distributor become a bottleneck if it’s delivering messages back and forth?
Even though the distributor is required to deliver the message from the client to a worker, it is not usedwhen a worker replies to the client. Instead, the worker sends the reply directly to the client’s input queue.
We can use this information to finish our NServiceBus distributor’s architecture sketch from “Using NServiceBus distributor”.
This means that your distributor can be down and still the worker can deliver the reply to the calling client.
New tutorials, community projects and NServiceBus patches. Not a bad week.
News
- Ask your questions on DDD, CQRS, Event Sourcing, NServiceBus - Q&A Session – Udi Dahan is giving a free event on DDD, CQRS, Event Sourcing, and NServiceBus. Event is scheduled to 14th of September and it’s located in London.
- Project Changes – Current revision: 1336. In the past week bugs related to testing were fixed, new 2.5 trunk was created and an encryption specific sample was added (plus some other changes). The trunk-version of NServiceBus (3.0) will be updated with a newer version of TopShelf (which is the nice project behind the generic host).
Tutorials and Articles
- Event based interop with Service Broker – Great post by Andreas Öhlund on how to get NServiceBus and SQL Server Service Broker to work together.
- Getting Started with NServiceBus Part 4: Handling Messages – Adam Fyles continues his great series where NServiceBus is used to improve the Music Store web app. This time Adam shows how one can implement a good UI by displaying changes on the client before the NServiceBus has processed the relevant messages.
- NServiceBus for Admins – Sorry, this link is older than a week but it’s a definite must read for everyone. This slide deck presents the overall architecture of NServiceBus very thoroughly.
Community
Got an interesting NServiceBus related link? Did I miss something? Link not working? Please, send mail or contact@MikaelKoskinen.
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):
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:
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:
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.
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.
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.
