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
Consul KVs seem like a good fit for counters that need to be sequential cluster wide. This can be implemented using PUT with the "cas" option set to the last known values ModifyIndex when updating the counter value. Unfortunately this seems to always require re-fetching the current value to get access to the current ModifyIndex, even if no other updates have occurred, as there is apparently no way for the successful PUT operation to return the new ModifyIndex and it's not reliably predictable either.
If the PUT operation were to return the new ModifyIndex, either as JSON or as an additional header, it would be possible to optimistically update the value without refetching, in cases where concurrent updates are rare. I doubt you'll be eager to change the return value of PUT, as it would break existing code, but adding an additional "X-Consul-ModifyIndex" should not be disruptive. This header could also be added for GETs, then the "raw" option could be used in this case and Base64+JSON coding of the value could be avoided. (You may want to add the other fields from the JSON response as headers as well for consistency.)
The text was updated successfully, but these errors were encountered:
Consul KVs seem like a good fit for counters that need to be sequential cluster wide. This can be implemented using PUT with the "cas" option set to the last known values ModifyIndex when updating the counter value. Unfortunately this seems to always require re-fetching the current value to get access to the current ModifyIndex, even if no other updates have occurred, as there is apparently no way for the successful PUT operation to return the new ModifyIndex and it's not reliably predictable either.
If the PUT operation were to return the new ModifyIndex, either as JSON or as an additional header, it would be possible to optimistically update the value without refetching, in cases where concurrent updates are rare. I doubt you'll be eager to change the return value of PUT, as it would break existing code, but adding an additional "X-Consul-ModifyIndex" should not be disruptive. This header could also be added for GETs, then the "raw" option could be used in this case and Base64+JSON coding of the value could be avoided. (You may want to add the other fields from the JSON response as headers as well for consistency.)
The text was updated successfully, but these errors were encountered: