[jira] [Commented] (CASSANDRA-15159) Purgable tombstones are ignored by read query
[ https://issues.apache.org/jira/browse/CASSANDRA-15159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868997#comment-16868997 ] Ben Krug commented on CASSANDRA-15159: -- I don't see this as a bug. The behavior is the same as the behavior that would result if those purgeable tombstones had in fact been purged. So the request here is saying, "give me extra protection if compaction hasn't done its job and cleaned these up yet, even though it could have". This is another (or the same) example of why it's important to do repairs in less than gc_grace_seconds. > Purgable tombstones are ignored by read query > - > > Key: CASSANDRA-15159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15159 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Laxmikant Upadhyay >Priority: Normal > Attachments: steps2reproduce.txt, trace.txt > > > In 3 node Cassandra cluster, one node has old mutation and two nodes have > evict-able (crossed gc grace period) tombstone produced by TTL. A read query > with local quorum return the old mutation as result when one request goes to > the node having old mutation. However expected result should be empty. > Attached the steps to reproduce and trace of read query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15041) UncheckedExecutionException if authentication/authorization query fails
[
https://issues.apache.org/jira/browse/CASSANDRA-15041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868818#comment-16868818
]
Sam Tunnicliffe edited comment on CASSANDRA-15041 at 6/20/19 7:38 PM:
--
Thanks for this [~eperott], there are definitely valuable improvements here.
Whilst the new dtests for handling unavailability do what they claim, they’re
not doing so in the way one *might* expect. First of all, because they use a
superuser, table/keyspace level permissions will never be read from system
tables and so won’t be vulnerable to unavailablity. The reason the tests are
currently passing is that the check that the user has access to the local DC is
resulting in a failed read by {{CassandraNetworkAuthorizer}}. So the tests are
definitely still valid as they are, but it might be worth adding some
commentary just to highlight this and maybe use a non-superuser role that
*could* exercise the permissions cache too (even though it won't with the way
the current test are organised). Potentially, adding some logging to the new
catch blocks in {{CassandraRoleManager}} might be useful, similar to that in
{{CassandraAuthorizer::authorize}}. {{CassandraNetworkAuthorizer}} is
especially vulnerable here, due to CASSANDRA-15089, which I will commit as soon
as I get chance.
Otherwise, this all looks pretty good to me, modulo a typo in
{{ClientState::canLogin}} (only in 2.2/3.0/3.11).
I’ve been running the tests with the HIRES circle configuration and everything
looks good - all failures are unrelated and/or fixed already by other tickets.
So I just have these nits:
* typo in {{ClientState::canLogin}} (2.2/3.0/3.11)
* maybe add some minimal logging in {{CassandraRoleManager::isSuper/canLogin}}
or make the exception messages distinguishable
* document the potential sources of the availability failures that the dtests
are checking and/or use a non-superuser in tests
One thing that I had missed up to now was that when Guava was replaced with
Caffeine in CASSANDRA-10855, the ability to do async reloading in {{AuthCache}}
was lost. We should definitely fix that, as having those reads done in a thread
servicing client reads is not a good idea. I’ve opened CASSANDRA-15177 for
that.
was (Author: beobal):
Thanks for this [~eperott], there are definitely valuable improvements here.
Whilst the new dtests for handling unavailability do what they claim, they’re
not doing so in the way one *might* expect. First of all, because they use a
superuser, table/keyspace level permissions will never be read from system
tables and so won’t be vulnerable to unavailablity. The reason the tests are
currently passing is that the check that the user has access to the local DC is
resulting in a failed read by {{CassandraNetworkAuthorizer}}. So the tests are
definitely still valid as they are, but it might be worth adding some
commentary just to highlight this and maybe use a non-superuser role to
exercise the permissions cache too. Potentially, adding some logging to the new
catch blocks in {{CassandraRoleManager}} might be useful, similar to that in
{{CassandraAuthorizer::authorize}}. {{CassandraNetworkAuthorizer}} is
especially vulnerable here, due to CASSANDRA-15089, which I will commit as soon
as I get chance.
Otherwise, this all looks pretty good to me, modulo a typo in
{{ClientState::canLogin}} (only in 2.2/3.0/3.11).
I’ve been running the tests with the HIRES circle configuration and everything
looks good - all failures are unrelated and/or fixed already by other tickets.
So I just have these nits:
* typo in {{ClientState::canLogin}} (2.2/3.0/3.11)
* maybe add some minimal logging in {{CassandraRoleManager::isSuper/canLogin}}
or make the exception messages distinguishable
* document the potential sources of the availability failures that the dtests
are checking and/or use a non-superuser in tests
One thing that I had missed up to now was that when Guava was replaced with
Caffeine in CASSANDRA-10855, the ability to do async reloading in {{AuthCache}}
was lost. We should definitely fix that, as having those reads done in a thread
servicing client reads is not a good idea. I’ve opened CASSANDRA-15177 for
that.
> UncheckedExecutionException if authentication/authorization query fails
> ---
>
> Key: CASSANDRA-15041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15041
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
>
> If cache update for permissions/credentials/roles fails with
> UnavailableException this comes back to client as UncheckedExecutionException.
[jira] [Commented] (CASSANDRA-15041) UncheckedExecutionException if authentication/authorization query fails
[
https://issues.apache.org/jira/browse/CASSANDRA-15041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868818#comment-16868818
]
Sam Tunnicliffe commented on CASSANDRA-15041:
-
Thanks for this [~eperott], there are definitely valuable improvements here.
Whilst the new dtests for handling unavailability do what they claim, they’re
not doing so in the way one *might* expect. First of all, because they use a
superuser, table/keyspace level permissions will never be read from system
tables and so won’t be vulnerable to unavailablity. The reason the tests are
currently passing is that the check that the user has access to the local DC is
resulting in a failed read by {{CassandraNetworkAuthorizer}}. So the tests are
definitely still valid as they are, but it might be worth adding some
commentary just to highlight this and maybe use a non-superuser role to
exercise the permissions cache too. Potentially, adding some logging to the new
catch blocks in {{CassandraRoleManager}} might be useful, similar to that in
{{CassandraAuthorizer::authorize}}. {{CassandraNetworkAuthorizer}} is
especially vulnerable here, due to CASSANDRA-15089, which I will commit as soon
as I get chance.
Otherwise, this all looks pretty good to me, modulo a typo in
{{ClientState::canLogin}} (only in 2.2/3.0/3.11).
I’ve been running the tests with the HIRES circle configuration and everything
looks good - all failures are unrelated and/or fixed already by other tickets.
So I just have these nits:
* typo in {{ClientState::canLogin}} (2.2/3.0/3.11)
* maybe add some minimal logging in {{CassandraRoleManager::isSuper/canLogin}}
or make the exception messages distinguishable
* document the potential sources of the availability failures that the dtests
are checking and/or use a non-superuser in tests
One thing that I had missed up to now was that when Guava was replaced with
Caffeine in CASSANDRA-10855, the ability to do async reloading in {{AuthCache}}
was lost. We should definitely fix that, as having those reads done in a thread
servicing client reads is not a good idea. I’ve opened CASSANDRA-15177 for
that.
> UncheckedExecutionException if authentication/authorization query fails
> ---
>
> Key: CASSANDRA-15041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15041
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
>
> If cache update for permissions/credentials/roles fails with
> UnavailableException this comes back to client as UncheckedExecutionException.
> Stack trace on server side:
> {noformat}
> ERROR [Native-Transport-Requests-1] 2019-03-04 16:30:51,537
> ErrorMessage.java:384 - Unexpected exception during request
> com.google.common.util.concurrent.UncheckedExecutionException:
> com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.RuntimeException:
> org.apache.cassandra.exceptions.UnavailableException: Cannot achieve
> consistency level QUORUM
> at
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203)
> ~[guava-18.0.jar:na]
> at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
> ~[guava-18.0.jar:na]
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
> ~[guava-18.0.jar:na]
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
> ~[guava-18.0.jar:na]
> at org.apache.cassandra.auth.AuthCache.get(AuthCache.java:97)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.auth.PermissionsCache.getPermissions(PermissionsCache.java:45)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.auth.AuthenticatedUser.getPermissions(AuthenticatedUser.java:104)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.service.ClientState.authorize(ClientState.java:439)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.service.ClientState.checkPermissionOnResourceChain(ClientState.java:368)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:345)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:332)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:310)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.checkAccess(ModificationStatement.java:211)
>
[jira] [Updated] (CASSANDRA-15177) Reloading of auth caches happens on the calling thread
[
https://issues.apache.org/jira/browse/CASSANDRA-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15177:
Severity: Normal
Complexity: Normal
Discovered By: New Unit Test
Bug Category: Parent values: Degradation(12984)Level 1 values: Performance
Bug/Regression(12997)
Component/s: (was: Legacy/Local Write-Read Paths)
Status: Open (was: Triage Needed)
> Reloading of auth caches happens on the calling thread
> --
>
> Key: CASSANDRA-15177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15177
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Priority: Normal
>
> When Guava caches were replaced by their Caffeine equivalents in
> CASSANDRA-10855, the async reloading of stale AuthCache entries was lost due
> to the use of {{MoreExecutors.directExecutor()}} to provide the delegate
> executor. Under normal conditions, we can expect these operations to be
> relatively expensive, and in failure scenarios where replicas for the auth
> data are DOWN this will greatly increase latency, so they shouldn’t be done
> on threads servicing requests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15176:
Discovered By: New Unit Test (was: Code Inspection)
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15177) Reloading of auth caches happens on the calling thread
Sam Tunnicliffe created CASSANDRA-15177:
---
Summary: Reloading of auth caches happens on the calling thread
Key: CASSANDRA-15177
URL: https://issues.apache.org/jira/browse/CASSANDRA-15177
Project: Cassandra
Issue Type: Bug
Components: Feature/Authorization, Legacy/Local Write-Read Paths
Reporter: Sam Tunnicliffe
When Guava caches were replaced by their Caffeine equivalents in
CASSANDRA-10855, the async reloading of stale AuthCache entries was lost due to
the use of {{MoreExecutors.directExecutor()}} to provide the delegate executor.
Under normal conditions, we can expect these operations to be relatively
expensive, and in failure scenarios where replicas for the auth data are DOWN
this will greatly increase latency, so they shouldn’t be done on threads
servicing requests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15176:
Discovered By: Code Inspection (was: New Unit Test)
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15108) Support building Cassandra with JDK 11
[ https://issues.apache.org/jira/browse/CASSANDRA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868710#comment-16868710 ] Blake Eggleston commented on CASSANDRA-15108: - bq. The change here removed the additional source folder for Java 11 specific stuff, to be able to add support for example for Direct-I/O (CASSANDRA-14466) or use the new ByteBuffer.mismatch(). We can add separate source directories in the future if they’re needed, although I think we should avoid them. CASSANDRA-14466 won’t be making it into 4.0, and it seems plausible that the next major release will only support java11+. bq. C* built w/ Java 11 doesn't work on Java 8 ((Byte)Buffer in particular) The intent is that a java 8 build would run on both java 8 and java 11 without requiring java 11 during compilation. Then if you wanted to build with java 11 you could, but it would only run on java 11+. > Support building Cassandra with JDK 11 > -- > > Key: CASSANDRA-15108 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15108 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > With the changes in java 8 support and licensing, we should be able to build > and run Cassandra with java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15176:
--
Status: Review In Progress (was: Patch Available)
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15176:
--
Reviewers: Blake Eggleston, Sam Tunnicliffe
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15176:
--
Test and Documentation Plan: Expanded unit test coverage
Status: Patch Available (was: Open)
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15176:
--
Severity: Normal
Complexity: Normal
Discovered By: New Unit Test
Bug Category: Parent values: Availability(12983)Level 1 values: Response
Crash(12991)
Status: Open (was: Triage Needed)
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
[
https://issues.apache.org/jira/browse/CASSANDRA-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868607#comment-16868607
]
Aleksey Yeschenko commented on CASSANDRA-15176:
---
3.0 branch [here|https://github.com/iamaleksey/cassandra/commits/15176-3.0],
others upcoming.
> Fix PagingState deserialization when the state was serialized using protocol
> version different from current session's
> -
>
> Key: CASSANDRA-15176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how {{PagingState}} is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> This is obviously sub-optimal, but also avoidable. This JIRA fixes one half
> of the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can
> do this by inspecting the byte buffer to verify if it's been indeed
> serialized with the protocol version used by the session, and if not, use the
> other method of deserialization.
> It should be noted that we list this as a 'known limitation' somewhere, but
> really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15176) Fix PagingState deserialization when the state was serialized using protocol version different from current session's
Aleksey Yeschenko created CASSANDRA-15176:
-
Summary: Fix PagingState deserialization when the state was
serialized using protocol version different from current session's
Key: CASSANDRA-15176
URL: https://issues.apache.org/jira/browse/CASSANDRA-15176
Project: Cassandra
Issue Type: Bug
Components: Messaging/Client
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
3.0 and native protocol V4 introduced a change to how {{PagingState}} is
serialized. Unfortunately that can break requests during upgrades: since paging
states are opaque, it's possible for a client to receive a paging state encoded
as V3 on a 2.1 node, and then send it to a 3.0 node on a V4 session. The
version of the current session will be used to deserialize the paging state,
instead of the actual version used to serialize it, and the request will fail.
This is obviously sub-optimal, but also avoidable. This JIRA fixes one half of
the problem: 3.0 failing to deserialize 'mislabeled' paging states. We can do
this by inspecting the byte buffer to verify if it's been indeed serialized
with the protocol version used by the session, and if not, use the other method
of deserialization.
It should be noted that we list this as a 'known limitation' somewhere, but
really this is an upgrade-blocking bug for some users of C*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15088) PagingTest failure on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Per Otterström updated CASSANDRA-15088:
---
Resolution: Duplicate
Status: Resolved (was: Open)
Was fixed by CASSANDRA-15066
> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
> at
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
> at
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
> at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO [main] 2019-04-11 15:32:29,916 Node
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
> storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED,
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled,
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15088) PagingTest failure on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Per Otterström updated CASSANDRA-15088:
---
Status: Open (was: Patch Available)
> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
> at
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
> at
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
> at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO [main] 2019-04-11 15:32:29,916 Node
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
> storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED,
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled,
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15088) PagingTest failure on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868419#comment-16868419
]
Marcus Olsson commented on CASSANDRA-15088:
---
[~eperott] No objections here
> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
> at
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
> at
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
> at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO [main] 2019-04-11 15:32:29,916 Node
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
> storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED,
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled,
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14757) GCInspector "Error accessing field of java.nio.Bits" under java11
[
https://issues.apache.org/jira/browse/CASSANDRA-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-14757:
-
Status: Ready to Commit (was: Review In Progress)
+1
> GCInspector "Error accessing field of java.nio.Bits" under java11
> -
>
> Key: CASSANDRA-14757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14757
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Jason Brown
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11, pull-request-available
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running under java11, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2018-09-18 05:18:25,905 GCInspector.java:78 - Error accessing
> field of java.nio.Bits
> java.lang.NoSuchFieldException: totalCapacity
> at java.base/java.lang.Class.getDeclaredField(Class.java:2412)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:72)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:308)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:590)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
> {noformat}
> This is because {{GCInspector}} uses reflection to read the {{totalCapacity}}
> from {{java.nio.Bits}}. This field was renamed to {{TOTAL_CAPACITY}}
> somewhere between java8 and java11.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by {{ByteBuffer}}s. If we fail to read the field, we simply return
> -1 for the metric value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14757) GCInspector "Error accessing field of java.nio.Bits" under java11
[
https://issues.apache.org/jira/browse/CASSANDRA-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-14757:
-
Status: Review In Progress (was: Patch Available)
> GCInspector "Error accessing field of java.nio.Bits" under java11
> -
>
> Key: CASSANDRA-14757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14757
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Jason Brown
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11, pull-request-available
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running under java11, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2018-09-18 05:18:25,905 GCInspector.java:78 - Error accessing
> field of java.nio.Bits
> java.lang.NoSuchFieldException: totalCapacity
> at java.base/java.lang.Class.getDeclaredField(Class.java:2412)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:72)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:308)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:590)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
> {noformat}
> This is because {{GCInspector}} uses reflection to read the {{totalCapacity}}
> from {{java.nio.Bits}}. This field was renamed to {{TOTAL_CAPACITY}}
> somewhere between java8 and java11.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by {{ByteBuffer}}s. If we fail to read the field, we simply return
> -1 for the metric value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15088) PagingTest failure on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868377#comment-16868377
]
maxwellguo commented on CASSANDRA-15088:
yes, i also meet this problem, and create a issue but latter i found this have
been fixed .
> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
> at
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
> at
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
> at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO [main] 2019-04-11 15:32:29,916 Node
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
> storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED,
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled,
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15088) PagingTest failure on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868369#comment-16868369
]
Per Otterström commented on CASSANDRA-15088:
Looks like this got fixed by CASSANDRA-15066. I think we can close it. Any
objections [~molsson]?
> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
> at
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
> at
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
> at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO [main] 2019-04-11 15:32:29,916 Node
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
> storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED,
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled,
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15159) Purgable tombstones are ignored by read query
[ https://issues.apache.org/jira/browse/CASSANDRA-15159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868314#comment-16868314 ] Laxmikant Upadhyay edited comment on CASSANDRA-15159 at 6/20/19 7:30 AM: - Thanks [~eperott] for your analysis. You are right, it is annoying and getting resurrected data in this condition seems a violation of "last write wins" rule. However replicating old mutation during the read repair again looks an issue as explained by you. was (Author: laxmikant99): Thanks [~eperott] for your analysis. You are right, it is annoying and getting resurrected data in this condition seems a violation of "last write wins" rule. However replicating old mutation during the read repair again looks an issue explained by your. > Purgable tombstones are ignored by read query > - > > Key: CASSANDRA-15159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15159 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Laxmikant Upadhyay >Priority: Normal > Attachments: steps2reproduce.txt, trace.txt > > > In 3 node Cassandra cluster, one node has old mutation and two nodes have > evict-able (crossed gc grace period) tombstone produced by TTL. A read query > with local quorum return the old mutation as result when one request goes to > the node having old mutation. However expected result should be empty. > Attached the steps to reproduce and trace of read query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15159) Purgable tombstones are ignored by read query
[ https://issues.apache.org/jira/browse/CASSANDRA-15159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868314#comment-16868314 ] Laxmikant Upadhyay commented on CASSANDRA-15159: Thanks [~eperott] for your analysis. You are right, it is annoying and getting resurrected data in this condition seems a violation of "last write wins" rule. However replicating old mutation during the read repair again looks an issue explained by your. > Purgable tombstones are ignored by read query > - > > Key: CASSANDRA-15159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15159 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Laxmikant Upadhyay >Priority: Normal > Attachments: steps2reproduce.txt, trace.txt > > > In 3 node Cassandra cluster, one node has old mutation and two nodes have > evict-able (crossed gc grace period) tombstone produced by TTL. A read query > with local quorum return the old mutation as result when one request goes to > the node having old mutation. However expected result should be empty. > Attached the steps to reproduce and trace of read query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
