Skip to main content

RabbitMQ Streams–Reliable producers

Last week I introduced RabbitMQ streams and how you could produce and consume streams through the RabbitMQ.Stream.Client in .NET.

The default Producer is really low-level and leaves a lot of things to be implemented by us. For example, we have to increment the PublishingId ourselves with every Send() operation. Let’s find out how we can improve this through Reliable Producers.

Introducing Reliable Producers

Reliable Producer builts on top of the Producer and adds the following features:

  • Provide publishingID automatically
  • Auto-Reconnect in case of disconnection
  • Trace sent and received messages
  • Invalidate messages
  • Handle the metadata Update

Provide publishingID automatically

When using a Reliable Producer it retrieves the last publishingID given the producer name.  This means that it becomes important to choose a good reference value.

Auto-Reconnect

The Reliable Producer  will try to restore the TCP connection when the Producer is disconnected for some reason.

Trace sent and received messages

The Reliable Producer keeps each sent message in memory and removes it from memory when the message is confirmed or goes in timeout.

Invalidate messages

If the client doesn't receive a confirmation within 2 seconds the Reliable Producer removes the message from the internal messages cache. The user will receive ConfirmationStatus.TimeoutError in the ConfirmationHandler.

Handle the metadata update

If the streams  topology changes (ex:Stream deleted or add/remove follower), the client receives an MetadataUpdate event. The Reliable Producer detects this event and tries to reconnect the producer if the stream still exist or closes the producer/consumer when the stream is deleted.

Sending messages through Reliable Producers

The Reliable Producer also provides a Send() method but only requires the message as parameter because the publishingId is provided automatically:

Popular posts from this blog

XUnit - Assert.Collection

A colleague asked me to take a look at the following code inside a test project: My first guess would be that this code checks that the specified condition(the contains) is true for every element in the list.  This turns out not to be the case. The Assert.Collection expects a list of element inspectors, one for every item in the list. The first inspector is used to check the first item, the second inspector the second item and so on. The number of inspectors should match the number of elements in the list. An example: The behavior I expected could be achieved using the Assert.All method:

Angular --deploy-url and --base-href

As long you are running your Angular application at a root URL (e.g. www.myangularapp.com ) you don’t need to worry that much about either the ‘--deploy-url’ and ‘--base-href’ parameters. But once you want to serve your Angular application from a server sub folder(e.g. www.mywebsite.com/angularapp ) these parameters become important. --base-href If you deploy your Angular app to a subfolder, the ‘--base-href’ is important to generate the correct routes. This parameter will update the <base href> tag inside the index.html. For example, if the index.html is on the server at /angularapp/index.html , the base href should be set to <base href="/angularapp/"> . More information: https://angular.io/guide/deployment --deploy-url A second parameter that is important is ‘--deploy-url’. This parameter will update the generated url’s for our assets(scripts, css) inside the index.html. To make your assets available at /angularapp/, the deploy url should

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.