Roman Gershman

one one instance of failed takeover client list gave me: ``` fd=57 name=56 tid=0 irqmatch=1 pipeline=10001 pbuf=33925021 age=15391 idle=1 tot-cmds=27 tot-net-in=103741370850 tot-read-calls=3208868 tot-dispatches=176658048 fd=72 name=71 tid=2 irqmatch=1 pipeline=10001 pbuf=32874119 age=15388...

Same command with valkey: ``` docker run --network="host" --rm --cpuset-cpus="2-3" valkey/valkey:9.0 --save "" --appendonly no --protected-mode no ``` reaches almost double throughput. (this scenario is not common in prod, the...

@adiholden please rebase

@mkaruza is this still needed?

Duplicate of #5881 and https://github.com/dragonflydb/dragonfly-operator/issues/397 In my opinion, the correct approach is to implement this at the operator/helm chart level, and configure a custom readiness probe for k8s. We'd gladly...

something along these lines: ``` pod.Spec: volumeMounts: - name: script-volume mountPath: /scripts startupProbe: exec: command: - /scripts/readiness-check.sh volumes: - name: health-script-volume configMap: name: health-script-cm ```

@kostasrim can you please write in the PR description the **existing** algorithm behind takeover? specifically, Is it a stateful flow operation where we tell listener to stop accepting new connections,...

> The rationale a long time ago was really simple: once we set TAKEN_OVER state, not all connections might have finished running transactions. So to keep data integrity/operation atomicity, we...

I added additional logs which I hope will shed more light on why takeover fails BESIDES the stuck send explanation. Btw, stuck send is relatively rare phenomena for us and...

There is a problem with this design. You use shared_ptr to be able to access the object even if it's "released" in another thread. But `ProtocolClient` is *designed* to be...