🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Clarification on how to correctly handle DownError events to preserve message order
In the documentation I see the following paragraphs:
Multi-threaded applications should be aware that some, but not necessarily all, messages published on one thread may be flushed due to failed reconnect, as messages published after the DownError event are not flushed. If the application chooses to republish some or all unacknowledged messages after the send queue has been flushed there is a possibility that these old, republished messages may be queued after newly published messages.
If the possibility of old messages after new messages is a concern, it is recommended that instead of calling Connect() on the session that has gone down, this session should instead be destroyed and a new session created to establish a new connection.
Elsewhere the documentation also indicates that:
Disposing a session must not be performed in a session callback delegate for the session being disposed. This includes all flows on the session.
Prima facie, these directives seem to conflict with each other.
What is the intended pattern fort "destroying" a session on receiving a DownError event?
Answers
-
The Solace API for .NET is a managed interface for a native C library. It follows the disposable pattern for memory management on all the native objects. That is, best practice is Session objects should be explicitly disposed by calling Dispose(). That said you may just let the object go out of scope and the API will do it's best. Your mileage may vary.
However, it is not possible to Dispose() the session from a callback, as this is in effect destroying the object while within a method on that object. Your main business logic will need to Dispose() of the Session.
You likely already have certain states, events, or triggers that cause it to Dispose() the session, so the DownError event is just one more. You can add it to your event/message processing queue, to be handled in the main thread of your application, and Dispose() the session from there.
1
