You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 31, 2022. It is now read-only.
Cassandra gives each repair command a unique hash, which is not the same as the repair number which we already track. It might be convenient to have this hash in the repair segment, so that you can easily find the right repair command in the log on all nodes involved in the repair.
It has turned out this information is not propagated to the Reaper using JMX when a repair starts. The only time this ID reaches the Reaper is in case of a repair session failure. That is being handled in #103. Therefore I believe we can close this issue.
Cassandra gives each repair command a unique hash, which is not the same as the repair number which we already track. It might be convenient to have this hash in the repair segment, so that you can easily find the right repair command in the log on all nodes involved in the repair.
Example: repair #2b41cfb0-a93d-11e4-b542-f707d752ca5f
The text was updated successfully, but these errors were encountered: