When all connections are lost, we may as well reset the nodeid for logging and operational purposes, to avoid it getting excessively large. Also, start at 100 (makes searching the logs easier).
Reset node #4921
pull rebroad wants to merge 2 commits into bitcoin:master from rebroad:ResetNodeId changing 1 files +6 −1-
rebroad commented at 11:27 AM on September 15, 2014: contributor
-
Starting NodeId = 100 d63db6da38
-
Reset NodeId to START_NODEID when all connections lost. 44eb246069
-
BitcoinPullTester commented at 11:41 AM on September 15, 2014: none
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4921_44eb246069593a4d89b53b349a632e7edea11b01/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
-
laanwj commented at 2:58 PM on September 15, 2014: member
makes searching the logs easier
You could search for peer=1[^0-9] instead of peer=1.
Reset NodeId to START_NODEID when all connections lost
I'd - personally - prefer to maximize the time between reuse of node ids. Is there any concrete argument (apart from 'log aesthetics') for not letting it grow arbitrarily large?
-
sipa commented at 1:11 AM on September 16, 2014: member
NAK. This makes it harder to correlate different lines in the log across time.
- sipa closed this on Sep 16, 2014
- MarcoFalke locked this on Sep 8, 2021
Contributors