Previously was only set after callbacks were invoked, allowing additional messages to be sent while parts of the supporting infrastructure for the peer was being torn down.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Adds metrics to expose:
* height of best known block
* synchronizer in sync flag
* max peers
* Timestamp of current chain head
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Don't copy collections if we don't need to. Change types higher up if needed.
* Don't use Guava's Object.equal, use Java's Objects.equals.
** add errorprone test to enforce the banning of Guava's Objects class.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Change all Stream<?> getX() and Stream<?> x() methods to Stream<?> streanX methods, such as `Stream<Peer> streamIdlePeers()`
* Update coding conventions to reflect this.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Move RocksDBStats to it's own module. This also brings metrics to
metrics:core since none of our other module have nested modules but
they have peer modules.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Only specify discovery port explicitly when the discovery port differs
from the listening port.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Because of deep issues sometimes we get duplicate Peers that differ
in small ways. Tweak the test to verify we get all of the peers
we are expecting and to be tolerant of quasi-duplicate peers.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Number of metrics labels need to match up with constructor
* Number of labels must be consistant, so I split it into two metrics
* Also, naming best practices say that sum() and avg() of a metric
should be meaningful, separating into two metrics fixes that.
* fix style issues (finals, intellij warnings)
* Change NoOpMetrics to check label count.
* Cascading changes to support this in many support classes. Mostly places
we presumed all NoOpMetrics were equals.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
When receiving an AddPeer, or when loading the static-nodes.json file, pantheon
should not accept its own NodeID as a valid connection (however, this should not invalidate the static-nodes file).
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Most peers discovered on the network only define a single UDP port and have no explicitly defined TCP port. At least some of these peers are listening on the TCP port matching the advertised UDP port so assume the ports are the same and attempt a connection.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
When RemovePeer is invoked, the specified peer is removed from the "Maintained" connections in NettyP2p, and the connection to said peer is disconnected.
The peer is not added to the blacklist, on the premise that this behaviour will typically be used when peer-discovery is disabled, thus no future connection to the peer in question will be attempted (except via an AddPeer JSON RPC call).
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Maintain a staticnodes.json
The staticnodes.json file resides in the pantheon data directory,
is parsed at startup to determine which peers can be connected
to (aside from bootnodes), and is updated whenever addPeer/removePeer
RPC is invoked.
This file is not updated when finding neighbour peers (ONLY on RPC
call).
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>