-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bisq v1.2.8 fails to start on macOS catalina #4052
Comments
@wiz Could you please comment out in LocalBitcoinNode.java following lines:
and
and post again the logs. This should give us more indications what is going wrong in the NioClient and NioClientManager class. |
Also reproduced on Linux, and confirmed |
Running on ubuntu 19.10, java 11, I'm not having any issues running from release branch. |
Fixes bisq-network#4052, as the peer.close() already calls closeConnection if a writeTarget is established successfully.
@dmos62 I think I've found the issue. If a writeTarget can't be established because of some weird setup it will cause a NullPointerException. Anyways it was a redundant call that was triggered by the |
Fixes bisq-network#4052, as the peer.close() already calls closeConnection if a writeTarget is established successfully.
On linux, Bisq fails about 25% of the time to start, if I start 4 nodes 3 will start fine but 1 fails to start, and each time a different node fails |
Just as a note: In those cases the nodes are stuck at following log and the app doesn't startup:
|
That's weird. I use Linux and didn't experience that. @wiz does it only happen when starting many Bisq instances at the same time? With local Bitcoin instance or without? If it's getting stuck at the log entry @ripcurlx posted above, that could be the handshake progressing too slowly, but in that case I'd expect it to timeout (CONNECTION_TIMEOUT in LocalBitcoinNode). |
I wonder why @wiz it would be very useful if you could try reproducing the linux problems with the redundant |
Since the Linux issue is a different log output, I'll create a separate issue for that, and this one for the macOS issue is resolved |
Fixes #4052, as the peer.close() already calls closeConnection if a writeTarget is established successfully.
The text was updated successfully, but these errors were encountered: