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.
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.
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
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: