[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027827#comment-17027827
]
Yifan Cai edited comment on CASSANDRA-15350 at 1/31/20 9:41 PM:
Thanks Alex.
Using fuzz to reproduce contentions sounds OK to me.
Having deterministic test cases to precisely produce contentions is also
valuable, IMO. But I am good to not have those test cases being merged as of
now.
I rebased my branch with your improvements commit and added/tweaked test cases
in {{CasWriteTest}}.
Still the same [PR|https://github.com/apache/cassandra/pull/379] and [code
branch|https://github.com/yifan-c/cassandra/tree/cas-exception-changes]. Test
result is
[here.|https://app.circleci.com/github/yifan-c/cassandra/pipelines/8d10bf4b-9f36-468e-922c-18a6dcf7df81/workflows/d20b5ae8-cd82-49cb-9026-97644359ee76]
was (Author: yifanc):
Thanks Alex.
Using fuzz to reproduce contentions sounds OK to me.
Having deterministic test cases to precisely produce contentions is also
valuable, IMO. But I am good to not have those test cases being merged as of
now.
I rebased my branch with your improvements commit and added/tweaked test cases
in {{CasWriteTest}}.
Still the same [PR|https://github.com/apache/cassandra/pull/379] and [code
branch|https://github.com/yifan-c/cassandra/tree/cas-exception-changes]. Test
result is
[here.|https://app.circleci.com/github/yifan-c/cassandra/pipelines/458cafcb-117b-443a-ae6c-c089efd6a929/workflows/7742c20d-1a82-47a8-93d0-cc40a542db5f]
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971341#comment-16971341
]
Yifan Cai edited comment on CASSANDRA-15350 at 11/11/19 11:52 PM:
--
{quote}Moved the change to a separate ticket as it is not related to this one.
[CASSANDRA-15410|https://issues.apache.org/jira/browse/CASSANDRA-15410]{quote}
-The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8. -
The previous [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
was wrong. For the cases of writing with exact size, `reserveAndWriteUtf8`
should be called to avoid resizing the buffer.
I have refined the
[benchmarks|https://github.com/apache/cassandra/blob/e0b0c95433dfc3d71c4abcc5cd8ccf5ac622ccf9/test/microbench/org/apache/cassandra/test/microbench/Utf8StringEncodeBench.java]
and introduced 2 new ones that leverage the encodeSize from the previous step.
The result shows performance improvement.
{code:java}
[java] Benchmark Mode
CntScoreError Units
[java] Utf8StringEncodeBench.writeLongTextavgt
6 571.949 ± 19.791 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt
6 459.932 ± 27.790 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSizeSkipCalc avgt
6 216.085 ± 3.480 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt
6 62.775 ± 6.159 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt
6 44.071 ± 5.645 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSizeSkipCalc avgt
6 36.358 ± 5.135 ns/op
{code}
* writeLongText: the original implementation that calls
`ByteBufUtils.writeUtf8`. It over-estimates the size of string that causes
resizing the buffer.
* writeLongTextWithExactSize: calls `TypeSizes.encodeUTF8Length` to reserve the
exact size of bytes to write.
* writeLongTextWithExactSizeSkipCalc: optimize by removing calculating the UTF8
length. Because we calculated the encodeSize before encode for messages.
Therefore, the size of the final bytes is known, we can leverage this
information to just reserve using the remaining capacity.
was (Author: yifanc):
-The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8. -
The previous [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
was wrong. For the cases of writing with exact size, `reserveAndWriteUtf8`
should be called to avoid resizing the buffer.
I have refined the
[benchmarks|https://github.com/apache/cassandra/blob/e0b0c95433dfc3d71c4abcc5cd8ccf5ac622ccf9/test/microbench/org/apache/cassandra/test/microbench/Utf8StringEncodeBench.java]
and introduced 2 new ones that leverage the encodeSize from the previous step.
The result shows performance improvement.
{code:java}
[java] Benchmark Mode
CntScoreError Units
[java] Utf8StringEncodeBench.writeLongTextavgt
6 571.949 ± 19.791 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt
6 459.932 ± 27.790 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSizeSkipCalc avgt
6 216.085 ± 3.480 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt
6 62.775 ± 6.159 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt
6 44.071 ± 5.645 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSizeSkipCalc avgt
6 36.358 ± 5.135 ns/op
{code}
* writeLongText: the original implementation that calls
`ByteBufUtils.writeUtf8`. It over-estimates the size of string that causes
resizing the buffer.
* writeLongTextWithExactSize: calls `TypeSizes.encodeUTF8Length` to reserve the
exact size of bytes to write.
* writeLongTextWithExactSizeSkipCalc: optimize by removing calculating the UTF8
length. Because we calculated the encodeSize before encode for messages.
Therefore, the size of the final bytes is known, we can leverage this
information to just reserve using the remaining capacity.
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue
[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962289#comment-16962289
]
Yifan Cai edited comment on CASSANDRA-15350 at 11/11/19 11:51 PM:
--
||Branch||Diff||Tests||PR||
|[cas-exception-changes|https://github.com/yifan-c/cassandra/tree/cas-exception-changes]|[diff|https://github.com/apache/cassandra/compare/trunk...yifan-c:cas-exception-changes]|[tests|https://circleci.com/workflow-run/67f7d98f-5c2b-4b2c-9fd7-120862e554e7]|[PR|https://github.com/apache/cassandra/pull/379]|
Changes:
# Added {{CasWriteTimeoutException}} and {{CasWriteUncertaintyException}}
# Added {{encode}}/{{decode}}/{{encodeSize}} for the new exceptions. Test
cases added in ErrorMessageTest
# Modified {{MessageFilters}} in dtest to support constructing CAS scenario.
# Added CasWriteTest.
# Minor changes
** -Calculate the exact UTF-8 string byte size in CBUtil to reduce unnecessary
memory allocation, (over-estimating with utf8MaxBytes)-
** Corrected {{assertRows}} parameters sequence
** Moved {{DatabaseDescriptor}} initialization for dtest to test base class.
was (Author: yifanc):
||Branch||Diff||Tests||PR||
|[cas-exception-changes|https://github.com/yifan-c/cassandra/tree/cas-exception-changes]|[diff|https://github.com/apache/cassandra/compare/trunk...yifan-c:cas-exception-changes]|[tests|https://circleci.com/workflow-run/67f7d98f-5c2b-4b2c-9fd7-120862e554e7]|[PR|https://github.com/apache/cassandra/pull/379]|
Changes:
# Added {{CasWriteTimeoutException}} and {{CasWriteUncertaintyException}}
# Added {{encode}}/{{decode}}/{{encodeSize}} for the new exceptions. Test
cases added in ErrorMessageTest
# Modified {{MessageFilters}} in dtest to support constructing CAS scenario.
# Added CasWriteTest.
# Minor changes
** Calculate the exact UTF-8 string byte size in CBUtil to reduce unnecessary
memory allocation, (over-estimating with utf8MaxBytes)
** Corrected {{assertRows}} parameters sequence
** Moved {{DatabaseDescriptor}} initialization for dtest to test base class.
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971341#comment-16971341
]
Yifan Cai edited comment on CASSANDRA-15350 at 11/11/19 7:54 PM:
-
-The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8. -
The previous [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
was wrong. For the cases of writing with exact size, `reserveAndWriteUtf8`
should be called to avoid resizing the buffer.
I have refined the
[benchmarks|https://github.com/apache/cassandra/blob/e0b0c95433dfc3d71c4abcc5cd8ccf5ac622ccf9/test/microbench/org/apache/cassandra/test/microbench/Utf8StringEncodeBench.java]
and introduced 2 new ones that leverage the encodeSize from the previous step.
The result shows performance improvement.
{code:java}
[java] Benchmark Mode
CntScoreError Units
[java] Utf8StringEncodeBench.writeLongTextavgt
6 571.949 ± 19.791 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt
6 459.932 ± 27.790 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSizeSkipCalc avgt
6 216.085 ± 3.480 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt
6 62.775 ± 6.159 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt
6 44.071 ± 5.645 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSizeSkipCalc avgt
6 36.358 ± 5.135 ns/op
{code}
* writeLongText: the original implementation that calls
`ByteBufUtils.writeUtf8`. It over-estimates the size of string that causes
resizing the buffer.
* writeLongTextWithExactSize: calls `TypeSizes.encodeUTF8Length` to reserve the
exact size of bytes to write.
* writeLongTextWithExactSizeSkipCalc: optimize by removing calculating the UTF8
length. Because we calculated the encodeSize before encode for messages.
Therefore, the size of the final bytes is known, we can leverage this
information to just reserve using the remaining capacity.
was (Author: yifanc):
-The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8. -
The previous [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
was wrong. For the cases of writing with exact size, `reserveAndWriteUtf8`
should be called to avoid resizing the buffer.
I have refined the benchmarks and introduced 2 new ones that leverage the
encodeSize from the previous step. The result shows performance improvement.
{code:java}
[java] Benchmark Mode
CntScoreError Units
[java] Utf8StringEncodeBench.writeLongTextavgt
6 571.949 ± 19.791 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt
6 459.932 ± 27.790 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSizeSkipCalc avgt
6 216.085 ± 3.480 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt
6 62.775 ± 6.159 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt
6 44.071 ± 5.645 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSizeSkipCalc avgt
6 36.358 ± 5.135 ns/op
{code}
* writeLongText: the original implementation that calls
`ByteBufUtils.writeUtf8`. It over-estimates the size of string that causes
resizing the buffer.
* writeLongTextWithExactSize: calls `TypeSizes.encodeUTF8Length` to reserve the
exact size of bytes to write.
* writeLongTextWithExactSizeSkipCalc: optimize by removing calculating the UTF8
length. Because we calculated the encodeSize before encode for messages.
Therefore, the size of the final bytes is known, we can leverage this
information to just reserve using the remaining capacity.
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining
[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971341#comment-16971341
]
Yifan Cai edited comment on CASSANDRA-15350 at 11/11/19 6:02 PM:
-
-The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8. -
The previous [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
was wrong. For the cases of writing with exact size, `reserveAndWriteUtf8`
should be called to avoid resizing the buffer.
I have refined the benchmarks and introduced 2 new ones that leverage the
encodeSize from the previous step. The result shows performance improvement.
{code:java}
[java] Benchmark Mode
CntScoreError Units
[java] Utf8StringEncodeBench.writeLongTextavgt
6 571.949 ± 19.791 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt
6 459.932 ± 27.790 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSizeSkipCalc avgt
6 216.085 ± 3.480 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt
6 62.775 ± 6.159 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt
6 44.071 ± 5.645 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSizeSkipCalc avgt
6 36.358 ± 5.135 ns/op
{code}
* writeLongText: the original implementation that calls
`ByteBufUtils.writeUtf8`. It over-estimates the size of string that causes
resizing the buffer.
* writeLongTextWithExactSize: calls `TypeSizes.encodeUTF8Length` to reserve the
exact size of bytes to write.
* writeLongTextWithExactSizeSkipCalc: optimize by removing calculating the UTF8
length. Because we calculated the encodeSize before encode for messages.
Therefore, the size of the final bytes is known, we can leverage this
information to just reserve using the remaining capacity.
was (Author: yifanc):
The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8.
The [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
and the result:
{code:java}
[java] Benchmark Mode Cnt
Score Error Units
[java] Utf8StringEncodeBench.writeLongTextavgt6
552.458 ± 9.141 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt6
787.676 ± 120.057 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt6
70.311 ± 8.031 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt6
71.716 ± 4.790 ns/op
{code}
I will revert the change.
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971341#comment-16971341
]
Yifan Cai edited comment on CASSANDRA-15350 at 11/11/19 6:56 AM:
-
The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8.
The [benchmark
setup|https://issues.apache.org/jira/secure/attachment/12985494/Utf8StringEncodeBench.java]
and the result:
{code:java}
[java] Benchmark Mode Cnt
Score Error Units
[java] Utf8StringEncodeBench.writeLongTextavgt6
552.458 ± 9.141 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt6
787.676 ± 120.057 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt6
70.311 ± 8.031 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt6
71.716 ± 4.790 ns/op
{code}
I will revert the change.
was (Author: yifanc):
The change of calculating the exact size of UTF-8 string has negative
performance impact. It needs to iterate through the entire string to determine
the actual size in UTF-8.
The benchmark setup and the result:
{code:java}
[java] Benchmark Mode Cnt
Score Error Units
[java] Utf8StringEncodeBench.writeLongTextavgt6
552.458 ± 9.141 ns/op
[java] Utf8StringEncodeBench.writeLongTextWithExactSize avgt6
787.676 ± 120.057 ns/op
[java] Utf8StringEncodeBench.writeShortText avgt6
70.311 ± 8.031 ns/op
[java] Utf8StringEncodeBench.writeShortTextWithExactSize avgt6
71.716 ± 4.790 ns/op
{code}
I will revert the change.
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962289#comment-16962289
]
Yifan Cai edited comment on CASSANDRA-15350 at 11/4/19 10:29 PM:
-
||Branch||Diff||Tests||PR||
|[cas-exception-changes|https://github.com/yifan-c/cassandra/tree/cas-exception-changes]|[diff|https://github.com/apache/cassandra/compare/trunk...yifan-c:cas-exception-changes]|[tests|https://circleci.com/workflow-run/67f7d98f-5c2b-4b2c-9fd7-120862e554e7]|[PR|https://github.com/apache/cassandra/pull/379]|
Changes:
# Added {{CasWriteTimeoutException}} and {{CasWriteUncertaintyException}}
# Added {{encode}}/{{decode}}/{{encodeSize}} for the new exceptions. Test
cases added in ErrorMessageTest
# Modified {{MessageFilters}} in dtest to support constructing CAS scenario.
# Added CasWriteTest.
# Minor changes
** Calculate the exact UTF-8 string byte size in CBUtil to reduce unnecessary
memory allocation, (over-estimating with utf8MaxBytes)
** Corrected {{assertRows}} parameters sequence
** Moved {{DatabaseDescriptor}} initialization for dtest to test base class.
was (Author: yifanc):
||Branch||Diff||Tests||
|[cas-exception-changes|https://github.com/yifan-c/cassandra/tree/cas-exception-changes]|[diff|https://github.com/apache/cassandra/compare/trunk...yifan-c:cas-exception-changes]|[tests|https://circleci.com/workflow-run/67f7d98f-5c2b-4b2c-9fd7-120862e554e7]|
Changes:
# Added {{CasWriteTimeoutException}} and {{CasWriteUncertaintyException}}
# Added {{encode}}/{{decode}}/{{encodeSize}} for the new exceptions. Test
cases added in ErrorMessageTest
# Modified {{MessageFilters}} in dtest to support constructing CAS scenario.
# Added CasWriteTest.
# Minor changes
** Calculate the exact UTF-8 string byte size in CBUtil to reduce unnecessary
memory allocation, (over-estimating with utf8MaxBytes)
** Corrected {{assertRows}} parameters sequence
** Moved {{DatabaseDescriptor}} initialization for dtest to test base class.
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: client-impacting, protocolv5, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
