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?