Suppress p2p logs #1875
Suppress p2p logs #1875
Conversation
Some bots place limit orders then try to cancel some of them before a new block arrives. However, the order's id (in pending state) may be different in individual nodes, thus caused the exceptions. A potential solution to the order_id inconsistent issue: #556
abitmore
force-pushed
the
pr-978-p2p-logging
branch
from
2fc099d to
eea889d
Compare
|
The next large message in p2p log is
which followed with a JSON dump of a whole block due to the capture and re-throw of bitshares-core/libraries/app/application.cpp Line 635 in af8a01a The reason why this message appears in a normal node's log file, is when a normal node has a peer whose system clock is behind, the "stale" node may repeatedly reject / disconnect to the normal node and re-connect, the exception message with the whole block will be sent to the normal node when disconnecting. One stale node can generate 200+ such messages in normal nodes' log files every hour, which is 2-3 MB with recent blocks (depends on size of blocks). The more stale nodes connected, the more the messages, thus the larger the log files. On the other hand, the message could be helpful for nodes whose system clock is ahead. I'm not sure what's the best way to deal with this. My gut says we'd better send shorter message when disconnecting due to this reason, E.G. only includes the block header but not the whole block. Thoughts? |
|
Agree to send only message header and block header in this case. Returning the full block is waste of bandwidth + disk space. |
|
The code looks good. Any suggestions on how to effectively and easily test your changes? Side note: Do we need an appender that could help us with testing (i.e. appends to a vector)? |
|
@jmjatlanta one of my mainnet public API nodes is running the patched code. |
Some misconfigured bots were trying to place limit orders in unauthorized markets, or place orders when don't have sufficient balance (this could also be caused by inconsistent pending state).
libraries/net/node.cpp
Outdated
| case 3050105: // limit_order_create_receiving_asset_unauthorized | ||
| case 3050106: // limit_order_create_insufficient_balance | ||
| case 3050201: // limit_order_cancel_nonexist_order | ||
| case 3050202: // limit_order_cancel_owner_mismatch |
There was a problem hiding this comment.
I feel this code (a hard-coded list of magic numbers) is a bit ugly. Any idea to improve?
There was a problem hiding this comment.
Does using e. g. limit_order_cancel_nonexist_order::code_enum::code_value work?
There was a problem hiding this comment.
Thanks, it works.
But I still think hard-coding a list here is not very good, since we may need to add more items later. It would be better if we can make it somewhat configurable, e.g. can define the log level when throwing the exception, or use a config file, etc. Perhaps not worth the efforts though.
|
New log messages about "timestamp-in-the-future" blocks look like this:
Average size of such messages reduced from around 12KB (data of 2019-07-29) to 800 bytes. |
PR for #978.
This PR reduces logging level of some common exceptions, greatly reduce size of p2p log files.
Current implementation doesn't address the txid mismatch issue mentioned in #978 (comment).