[bisq-network/projects] Refactor send-message business logic in Connections (#28)

Florian Reimair notifications at github.com
Thu Apr 30 09:37:52 UTC 2020


> Even with a graceful shutdown there should be enough time to deliver the messages.

actually, before https://github.com/bisq-network/bisq/pull/4047, tor has been terminated before all messages have been flushed out. No RemoveOfferMsg, no CloseConnectionMsg. And, there is no central queue and there could be severe consequences to that. Here is the scenario:

1. A critical message might be "queued" in a UserThread.runAfter(>0, connection.sendMessage(.))
1. Thus, the connection does not know about the message yet
1. The business logic triggering the UserThread.runAfter assumes it has been sent (and depending on the message, may also memorizes that information)

Now, given, the client gets shut down before the message is sent, the business logic has no way of knowing that the message hasn't been sent (so no resend). Thus, we have a "lost" message.

> The message queued up are usually not much

Give it enough time and trials and it will happen.

> At shutdown of headless nodes there is/was no graceful shutdown

The issue we have been/are facing here is that the data store files got corrupted frequently. A graceful shutdown did help some. However, #25 and #29 will complement this very issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/projects/issues/28#issuecomment-621725436
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200430/8b73d584/attachment.html>


More information about the bisq-github mailing list