Anton Kaliaev 5f3048bd09

call FlushSync before calling CommitSync ...

if we call it after, we might receive a "fresh" transaction from
  `broadcast_tx_sync` before old transactions (which were not
  committed).

Refs #1091

```
Commit is called with a lock on the mempool, meaning no calls to CheckTx
can start. However, since CheckTx is called async in the mempool
connection, some CheckTx might have already "sailed", when the lock is
released in the mempool and Commit proceeds.

Then, that spurious CheckTx has not yet "begun" in the ABCI app (stuck
in transport?). Instead, ABCI app manages to start to process the
Commit. Next, the spurious, "sailed" CheckTx happens in the wrong place.
```

2018-01-23 16:56:14 +04:00

..

docs

Add skeleton for functionality and concurrency

2018-01-04 19:08:03 +01:00

mempool_test.go

mempool: cfg.CacheSize and expose InitWAL

2018-01-19 01:03:03 -05:00

mempool.go

call FlushSync before calling CommitSync

2018-01-23 16:56:14 +04:00

reactor_test.go

some more robust sleeps

2017-11-14 22:31:23 +00:00

reactor.go

mempool: remove Peer interface. use p2p.Peer

2017-12-26 20:24:12 -05:00