This removes the "25" limit for batched messages.
Turns out the aggregation in #1287 was not aggressive enough, because
it's quite possible to reach the specified max capacity of io vectors.
For example, each "QUEUED" is actually "+", "QUEUED", "\r\n" so we can
reach the limit with about 8 batched commands and then finish\
aggregating prematurely.
Closes#1285
To support this, I refactored some of the code:
* We no longer have `IsConfigured()` and `SetConfig()`, now
configuration validation is done via instantiation
* As a result, we check if `tl_cluster_config` is `nullptr` or not to
determine whether the cluster has been configured
* Reduce the size of the config by only storing 1 bit per slot (whether it's owned locally or not)
* Pushing new configuration is done via copy-c'tor
While at it, add a small test function to remove `sleep()`s and wait in a less fragile way.
Fixes#1357
Add support for cgroup v1 limit checking
For future reference: testing. In order to test this feature (both for
v1 and v2). To do this, create a cgroup and move Dragonfly into it
before running.
One way to do this is using a script, like: cat; ./dragonfly
--logtostderr
Enabling v1 (by default, you should have v2): Edit `/etc/default/grub`,
and look for `GRUB_CMDLINE_LINUX_DEFAULT`. Append to it
`systemd.unified_cgroup_hierarchy=0`, update GRUB using `sudo
updat-grub`, and reboot.
In v1, create a group `mycgroup` and add PID 1234 to it:
```
sudo mkdir -p /sys/fs/cgroup/memory/mycgroup
sudo bash -c "echo 8589934592 >
/sys/fs/cgroup/memory/mycgroup/memory.limit_in_bytes" # set mem limit to
8G
sudo bash -c "echo 1234 > /sys/fs/cgroup/memory/mycgroup/tasks" # assign
PID 1234 to this cgroup
```
In v2:
```
sudo mkdir -p /sys/fs/cgroup/mycgroup
sudo bash -c "echo 8589934592 > /sys/fs/cgroup/mycgroup/memory.max" #
set mem limit to 8G
sudo bash -c "echo 1234 > /sys/fs/cgroup/mycgroup/cgroup.procs" # assign
PID 1234 to this cgroup
```
then test by (using script example from before):
```
$ ./run.sh # contains: cat; ./dragonfly --logtostderr
[1] 1234
[1] + 1234 suspended (tty input) ./run.sh
fg
^D
<look for Dragonfly memory limit>
```
Signed-off-by: talbii <ido@dragonflydb.io>
This commit adds tracing logs for list commands to debug BLPOP crashes. This commit should be reverted once the issue is resolved
---------
Signed-off-by: Vladislav Oleshko <vlad@dragonflydb.io>
In this case, `redis.RedisCluster`.
To be double sure I also looked at the actual packets and saw that the
client asks for `CLUSTER SLOTS`, and then after the redistribution of
slots, following a few `MOVED` replied, it asks for the new slots again.
This allows masters to send data of non-owned keys to their replicas,
which is useful when:
1. Config is temporarily different between master and replica
2. Preparing for taking ownership over currently not-owned slots (in the upcoming migration feature)
Fixed#1319
* Chore: Clean up interface of Replica::ReadRespReply
* Combine SendCommand and ReadResp into SendCommandAndReadResponse
* Store sent command for better log message
* rename the macro
fix: fix crash when inserting to listpack empty value.
We can not pass null pointers to listpack.
Fixes#1305 and probably fixes#1290
Signed-off-by: Roman Gershman <roman@dragonflydb.io>
This makes the code more consistent with the other `CLUSTER` commands,
but more importantly it also unifies the place for reading the replica
info, which is important for refactoring it (next PR) to make it atomic
remove existing race.
* feat: Support ACKs from replica to master
* Rework after CR
* Split the acks into a different fiber and remove the PING loop
* const convention
* move around the order.
* revert sleep removal
* Exit ack fiber on cancellation
* Don't send ACKs if server doesn't support it
