Credits made to any account during the processing of a payment are delayed until
the payment completes, enforcing a new invariant: liquidity for any paths
during a payment's execution may never increase. This eliminates the need for special
code to handle a variety of corner cases where consuming liquidity in one path
increases liquidity in others.
For large data sets the JOIN may not make forward progress in time.
This prevents the deletion of those entries in the database during
online delete. The number of such entries is very small compared to
the total size of the data anyway. A future version will address
this more thoroughly.
* This silences a warning about a redundant cv-qualifier.
* This makes future coding mistakes about redundant
cv-qualifiers much less likely.
* This makes the code easier to read.
* Ownership of buffer memory in StatsDCollector is passed to the
boost::asio callback function. Before this, the memory may have been
freed before async_send was finished with the memory.
This solves a problem that caused a hang on shutdown related to
the lifetime of the ping timer completion handlers used in WebSockets.
* Turn the ping timer back on
* Use std::weak_ptr for WebSockets timer callbacks.
* Disable WebSocket pings if frequency in the .cfg is non-positive.
This gives requests for ledger data (and transaction set data)
from peers a separate job type and prioritizes it appropriately.
Previously it was lumped in with fetch packs which have a low
concurrency limit. This should improve the performance of
retrieving historical information.
This introduces the STVar container, capable of holding any STBase-derived
class and implementing a "small string" optimization. STObject is changed
to store std::vector<STVar> instead of boost::ptr_vector<STBase>. This
eliminates a significant number of needless dynamic memory allocations and
deallocations during transaction processing when ledger entries are
deserialized. It comes at the expense of larger overall storage requirements
for STObject.
* Use Request over json-rpc
* Use lodash to filter irrelevant fields from expectations
* Use LedgerState for state setup
* Test using limit and marker
Conflicts:
test/account_objects-test.js
General RPC command that can retrieve objects in the account root.
* Add account objects integration test.
* Support tickets.
* Add removeElement in Json::Value
* Each peer has a "sane/insane/unknown" status
* Status updated based on peer ledger sequence
* Status reported in peer json
* Only sane peers preferred for historical ledgers
* Overlay endpoints only accepted from known sane peers
* Untrusted proposals not relayed from insane peers
* Untrusted validations not relayed from insane peers
* Transactions from insane peers are not processed
* Periodically drop outbound connections to bad peers
* Bad peers get bootcache valence of zero
Peer "sanity" is based on the ledger sequence number they are on. We
quickly become able to assess this based on current trusted validations.
We quarrantine rogue messages and disconnect bad outbound connections to
help maintain the configured number of good outbound connections.
The 'account_index' field is expected to be an integer. If something
else is specified, the error message should clearly indicate which
field is at fault.
