The first few transactions are added to the open ledger at
the base fee (ie. 10 drops). Once enough transactions are
added, the required fee will jump dramatically. If additional
transactions are added, the fee will grow exponentially.
Transactions that don't have a high enough fee to be applied to
the ledger are added to the queue in order from highest fee to
lowest. Whenever a new ledger is accepted as validated, transactions
are first applied from the queue to the open ledger in fee order
until either all transactions are applied or the fee again jumps
too high for the remaining transactions.
Current implementation is restricted to one transaction in the
queue per account. Some groundwork has been laid to expand in
the future.
Note that this fee logic escalates independently of the load-based
fee logic (ie. LoadFeeTrack). Submitted transactions must meet
the load fee to be considered for the queue, and must meet both
fees to be put into open ledger.
* Remove cxx14 compatibility layer from ripple
* Update travis to clang 3.6 and drop gcc 4.8
* Remove unneeded beast CXX14 defines
* Do not run clang build with gdb with travis
* Update circle ci to clang 3.6 & gcc-5
* Don't run rippled in gdb, clang builds crash gdb
* Staticly link libstdc++, boost, ssl, & protobuf
* Support builds on ubuntu 15.10
The digest for a transaction (its transaction ID, or tid) is
computed once upon constructed when the STTx is deserialized.
Subsequent calls to retrieve the digest use the cached value.
Any code which modifies the STTx and then attempts to
retrieve the digest will terminate the process with a
logic error contract violation.
* Nested types removed
* All STTx are contained as const
(Except in transaction sign, which must modify)
* tid in STTx is computed once on deserialization
* All checks flow through ripple::checkValidity, which transparently caches result flags.
* All external transaction submission code paths use checkValidity.
* SF_SIGGOOD flag no longer appears outside of HashRouter / checkValidity.
* Validity can be forced in known or trusted scenarios.
* Track stats for ledger fetch and output
* Reduce entries queried on timeout
* Allow duplicate node requests on timeout
* Don't query deep on timeout
* Adjust latency tuning
* Change high latency cutoff
* Set absolute limit on reply entries
* Small optimizations
* Sanely handled specified ledger in account_tx
* Reject un-validated ledger in account_tx
* Wait to publish a ledger until it's indexed
* Add unit test for PendingSaves
* Remove ripple::RippleMutex and ripple::RippleRecursiveMutex
and use std::mutex and std::recursive_mutex respectively.
* Use std::lock_guard instead of std::unique_lock when the
additional features of std::unique_lock are not needed.
* Avoid throwing in OrderBookDB::processTxn
* Fix missing space in debug output
* Avoid duplicate lock of PathRequest in updateAll
* Avoid shadowing in insertPathRequest
* Improve indentation in runOnCoroutine
* Remove extraneous space in ServerHandlerImp::processRequest
Randomize the initial transaction execution order for closed
ledgers based on the hash of the consensus set. Transaction
processing change will take effect October 27, 2015 at
11:00 AM Pacific time.
The server's open ledger is now an instance of the OpenView
class, managed by an instance of the OpenLedger class. This
should improve the performance of operations on open ledgers
because they are no longer Ledger/SHAMap operation.
* Consider ledgers incompatible based on last valid ledger
* Test against even ledgers not acquired yet
* Don't validate an incompatible ledger
* Don't switch to an incompatible ledger
* Protect against an unreasonably small quorum
An instance of Rules provides information on the tx
processing rules in a particular ledger.
* OpenView allows rules to be set on construction.
Conflicts:
src/ripple/unity/ledger.cpp
This type alias provide cache-wrapping for Ledger objects.
Through the CachedLedger interface, access to the underlying
Ledger is permitted to allow for cases where the implementation
must perform Ledger specific activities. For example, building
a fetch pack from the contained SHAMap objects.
The CachingReadView is refactored:
* Renamed to CachedView
* Templated on Base, the base type
* base() returns a shared_ptr to the wrapped object
* Constructor requires a shared_ptr<Base>
