GitLab

from the block log used to be restricted to one reader or writer at a
time (a reader would hold an exclusive mutex for the duration of the
read).  This was required because the underlying implementation used
iostreams and depended on the seek and read operations to be
uninterrupted.  This replaces those reads with lower-level pread()
function which is safe to call from multiple threads.  There is still
a spin-lock guarding the cached head block, but the situation is
much better.
This also adds a get_block_range() function which allows you to request
up to 1000 blocks in a single call, which may improve hivemind sync
performance.

last block pushed, instead of calling the blockchain to get the
timestamp of block 0.  We don't need the actual time of the 0th block,
just a time that's older than any block we're actually going to be
pushing.

[DLN] set write_lock_hold_time as a function of block interval (1/6 of block time = 500ms for regular nodes that are more likely to serve API calls, 1/3 of block time (1 second) for block producing nodes where block production is the priority

[DLN] add logging to report unusual values for enable-stale-production and required-participation values for witness plugin

[DLN] make old account_history plugin use 0-based index like account_history_rocksdb, and fix start/limit assertion for account_history_rocksdb plugin

repiared 003, 004, 005 and 006 test in dhf test group, now they checks ballance ev ery hour, not at the end of the test

[DLN/EMF] return filtered results even if we don't find the requested amount. If we don't find any, throw an exception to report the item number to begin further searching from. None of this is ideal, but it's a temporary solution until we can get something more performant, such as using hivemind to supply this data.

remove unused validate_transaction function (becomes it grabs a write_lock and it's just distracting to see it in the code when it's not used). Comment the point in API processing where lock is set to true for API calls.

It was yielding the write much more often than intended.  Now it will
only yield the write lock after it has held the lock for 500ms.
In addition, we added a warning log message if it takes more than 50ms
to acquire a write lock (if it's being starved by long-running read
requests)

originally with read locks, but they are implemented as calls to the
underlying account_history_api, which already does the correct locking

our node to lock up when under load.  Instead, we allow the mutex's default
behavior which is fair (Terekhov) locking.

Reduce max limit on get_account_history from 10k blocks of operations to 1k blocks. 10k blocks puts a lot of strain on hived.

the last few arguments

position in the static variant

(it will only be used if the client supports it)

account_history_api::get_account_history methor has been extended by optional argument specifying an operation filter. \see hive_operations_filter enum definition.
condenser_api::get_account_history now can take optionally 4. parameter specifying operation filter (\see account_history_api::get_account_history description)

The operations `clear_null_account_balance_operation`, `consolidate_treasury_balance_operation` added to `get_impacted_account_visitor`

Partially eliminated IS_LOW_MEM #ifdefs breaking reward calculations. Still code must be cleaned and all code (specific to comment-content, child-parent comment traversal) which was performed only on FAT node.

condenser_api::get_accounts call shall also query for account reputation (if reputation plugin was enabled).