Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Port v1.2.4 and v1.2.5 #5720

Merged
merged 39 commits into from
Sep 18, 2018
Merged

Port v1.2.4 and v1.2.5 #5720

merged 39 commits into from
Sep 18, 2018

Conversation

wanderingbort
Copy link
Contributor

No description provided.

NorseGaud and others added 30 commits August 22, 2018 18:49
Apply all pending incoming transactions, even if not producing.
Really Bad Things can happen if multiple keosd are using the same wallet directory simultaneously. Like, loss of keys. Make a trivial locking mechanism so that this is prevented.
Trivial wallet directory locking for keosd
4904 add hint if launcher fails, more reliable port available check
"eosio_uninstall.sh --full" to delete directories with configs
The location of chainbase's mlock() is erroneously only encountered when the DB is constructed. Subsequent uses of a DB would not attempt a mlock(). Fix the location of this call. Also locking of the metadata was added.
(chainbase sync) Fix chainbase's mlock() to work on subsequent launches
fix abi serialization exception in get block
fix ambiguous command line option for filter-on/out
binaryen & softfloat libs are built within the main eos repo as git submodules
Unapplied transactions were only being pruned in a few instances:
- when an HTTP RPC request was made to the node, the node would persistently attempt to apply that transaction until it was done OR expired, cleaning it up appropriately
- when a Producer attempts to produce a block, it would apply as many unapplied transactions as it could, cleaning them up appropriately

This means that relay nodes which never produce would also never prune the unapplied list.

We now have 4 phases:

Phase 1) [If not a producing node] prune all unapplied transactions that are not "persisted" due to being directly received over HTTP RPC
Phase 2) [If potentially producing] prune all unapplied transactions that expired
Phase 3) [If not "read only"] attempt application of all unapplied transactions that are "persisted" due to being directly received over HTTP RPC
Phase 4) [If producing the next block] attempt application of all remaining unapplied transactions

Each of these phases potentially prunes.  Phases 1 & 2 are the new phases that cover P2P relays

Additionally, Read-only nodes were never pruning the unapplied transactions.  As they will never have need of them, nodes configured in this mode will unilaterally drop all unapplied transactions

However, a p2p relay node neither producers no accepts the transactions
…es are accounted for it is pretty simple to call out the one case where we can avoid fetching it explicitly
The mlock code was effectively inactive until 1.2.4. Enabling it has caused some unexpected support fallout. Remove it for now until a better solution is implemented in the future; performance will effectively be no worse than pre 1.2.4
@heifner heifner merged commit 0eee95f into develop Sep 18, 2018
@heifner heifner deleted the port/v1.2.4-and-v1.2.5 branch September 18, 2018 15:15
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants