Commit graph

34 commits

Author SHA1 Message Date
e8214cb180 Better concurrency:
Use Notify instead of stupid sleep in background worker
Use Semaphore to limit concurrent requests in rpc_client
Make more background tasks cancellable
2020-04-22 16:51:52 +00:00
ec59e896c6 Make UUID & Hash Copy and remove some .clone() noise 2020-04-21 17:08:42 +00:00
cc4f2f1cfb Pretty logging 2020-04-21 12:54:55 +00:00
04acaea231 Don't do version & block_ref updates in background on deletion 2020-04-19 20:52:20 +00:00
ea75564851 More aggressive sync timings & improve other stuff 2020-04-19 17:59:59 +00:00
a6129d8626 Begin implement bucket management & admin commands 2020-04-19 17:15:48 +02:00
302502f4c1 Add support for fully replicated tables with epidemic dissemination of updates 2020-04-19 15:14:23 +02:00
7131553c53 Refactor sharding logic; coming next: full replication with epidemic dissemination 2020-04-19 13:22:28 +02:00
f41583e1b7 Massive RPC refactoring 2020-04-18 19:21:34 +02:00
3f40ef149f Fix sync: use max root checksum level 2020-04-17 21:59:07 +02:00
40c48e6a59 Several resync workers; add delay on retry resync 2020-04-17 20:58:10 +02:00
29a1e94f23 Implement missing handler for read_range 2020-04-17 19:38:47 +02:00
db1c4222ce Don't send items...
...if syncer doesn't need them because he's going to delete the partition anyway.
Also, fix block resync queue
2020-04-17 18:51:29 +02:00
b780f6485d Make sync send data both ways 2020-04-17 18:27:29 +02:00
69f1d8fef2 WIP
TODOs:
- ensure sync goes both way
- finish sending blocks to other nodes when they need them before deleting
2020-04-17 17:09:57 +02:00
e41ce4d815 Implement getting missing blocks when RC increases
Issue: RC increases also when the block ref entry is first put by the actual client.
At that point the client is probably already sending us the block content,
so we don't need to do a get...
We should add a delay before the task is added or find something to do.
2020-04-17 15:40:13 +02:00
867646093b Table range deletion 2020-04-17 14:49:10 +02:00
6ce14e2c9e Make all requests continue in the background even after we got enough responses. 2020-04-16 23:13:15 +02:00
2f3b1a072f WIP 2020-04-16 19:28:02 +02:00
2832be4396 WIP 2020-04-16 18:41:10 +02:00
f01c1e71b5 Begin work on sync... 2020-04-16 14:50:49 +02:00
2bea76ce16 Small refactorings 2020-04-12 22:24:53 +02:00
9c931f5eda Keep network status & ring in a tokio::sync::watch
advantages
- reads don't prevent preparing writes
- can be followed from other parts of the system by cloning the receiver
2020-04-11 23:53:32 +02:00
dcf58499a4 table::insert_many, version_table::updated 2020-04-11 19:43:29 +02:00
ff4fb97568 (Try to) disable LTO ? 2020-04-10 22:55:01 +02:00
3477864142 Fix the Sync issue. Details:
So the HTTP client future of Hyper is not Sync, thus the stream
that read blocks wasn't either. However Hyper's default Body type
requires a stream to be Sync for wrap_stream. Solution: reimplement
a custom HTTP body type.
2020-04-10 22:01:48 +02:00
d66c0d6833 Why is it not Sync?? 2020-04-09 23:45:07 +02:00
a3eb88e601 Locally, transactions 2020-04-09 20:58:39 +02:00
1d786c2c66 Something works 2020-04-09 18:43:53 +02:00
101444abb3 Some progress 2020-04-09 17:32:28 +02:00
4c1aee42d5 Reorganize table API 2020-04-09 16:16:27 +02:00
a450103ed0 Work & TODO 2020-04-08 23:47:34 +02:00
cc580da0ae Some work 2020-04-08 23:01:49 +02:00
bacc76a057 Some work in actually storing things 2020-04-08 22:00:41 +02:00