[bisq-network/bisq] Merge P2P bugfixes into seednode branch to help node stability issues (#3155)

Florian Reimair notifications at github.com
Wed Aug 28 12:15:57 UTC 2019


freimair approved this pull request.

utAck

I am not sure if we should keep adding code and complexity to the project like this. Sure, there is an issue there that needs fixing, hence, utack. However, it seems to me that there is a simpler solution just around the corner.

> +
+
+    ///////////////////////////////////////////////////////////////////////////////////////////
+    // DaoSetupService
+    ///////////////////////////////////////////////////////////////////////////////////////////
+
+    @Override
+    public void addListeners() {
+    }
+
+    @Override
+    public void start() {
+        // We must set the listeners initially and not on onParseBlockChainComplete as activeOrMyUnconfirmedProposals
+        // is used in voteResults which can be called earlier during sync.
+        // To avoid unneeded upDateLists calls we delay one render frame so that once the proposalService is complete we
+        // register out listeners.

```suggestion
        // register our listeners.
```

> +    }
+
+
+    ///////////////////////////////////////////////////////////////////////////////////////////
+    // DaoSetupService
+    ///////////////////////////////////////////////////////////////////////////////////////////
+
+    @Override
+    public void addListeners() {
+    }
+
+    @Override
+    public void start() {
+        // We must set the listeners initially and not on onParseBlockChainComplete as activeOrMyUnconfirmedProposals
+        // is used in voteResults which can be called earlier during sync.
+        // To avoid unneeded upDateLists calls we delay one render frame so that once the proposalService is complete we

```suggestion
        // To avoid unneeded updateLists(); calls, we delay one render frame so that once the proposalService is complete, we
```

> @@ -31,7 +31,7 @@
     PROPOSAL,
     BLIND_VOTE,
     ACK_MSG,
-    BSQ_BLOCK,
+    RECEIVE_BSQ_BLOCK,

I am not sure we should change stuff like that. What I am sure of is that we should add Javadoc to describe what a capability is for and what it does, only so can we make sure devs can understand what these 2 or 3 words mean.

-- 
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/bisq/pull/3155#pullrequestreview-280780694
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190828/11678807/attachment.html>


More information about the bisq-github mailing list