[jira] [Assigned] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Tomassi reassigned CASSANDRA-14684:
Assignee: Massimiliano Tomassi
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Assignee: Massimiliano Tomassi
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> +Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
> The problem should be fixed in 3.0. It will merge cleanly to the other
> branches
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083119#comment-17083119
]
Massimiliano Tomassi commented on CASSANDRA-15667:
--
[~jasonstack], sorry for the delay. I've updated my first comment with links to
PRs against 3.0 and 3.11 too.
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076236#comment-17076236
]
Massimiliano Tomassi edited comment on CASSANDRA-15667 at 4/14/20, 11:16 AM:
-
||Pull Request||CI Links||
|[PR
4.0|https://github.com/maxtomassi/cassandra/pull/1]|[Circle-CI|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]|
|[PR
3.0|https://github.com/maxtomassi/cassandra/pull/2|https://github.com/maxtomassi/cassandra/pull/12]|[Circle-CI|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-3.0]|
|[PR
3.11|https://github.com/maxtomassi/cassandra/pull/3]|[Circle-CI|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-3.11]|
was (Author: maxtomassi):
||Pull Request||CI Links||
|[PR
4.0\|[https://github.com/maxtomassi/cassandra/pull/1]]|[Circle-CI\|[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]]|
|[PR
3.0\|[https://github.com/maxtomassi/cassandra/pull/2|https://github.com/maxtomassi/cassandra/pull/1]]|[Circle-CI\|[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-3.0|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]]|
|[PR
3.11\|[https://github.com/maxtomassi/cassandra/pull/3|https://github.com/maxtomassi/cassandra/pull/1]]|[Circle-CI\|[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-3.11|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]]|
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076236#comment-17076236
]
Massimiliano Tomassi edited comment on CASSANDRA-15667 at 4/14/20, 11:06 AM:
-
||Pull Request||CI Links||
|[PR
4.0\|[https://github.com/maxtomassi/cassandra/pull/1]]|[Circle-CI\|[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]]|
|[PR
3.0\|[https://github.com/maxtomassi/cassandra/pull/2|https://github.com/maxtomassi/cassandra/pull/1]]|[Circle-CI\|[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-3.0|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]]|
|[PR
3.11\|[https://github.com/maxtomassi/cassandra/pull/3|https://github.com/maxtomassi/cassandra/pull/1]]|[Circle-CI\|[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-3.11|https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]]|
was (Author: maxtomassi):
PR: [https://github.com/maxtomassi/cassandra/pull/1]
CircleCI:
[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]
(JVM dtests failed running)
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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] [Updated] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Tomassi updated CASSANDRA-15667:
-
Test and Documentation Plan:
[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]
It seems like JVM dtests fail to run properly. Lots of logs like this:
{code:java}
[junit-timeout] Testcase:
prepareRPCTimeout[PARALLEL/true](org.apache.cassandra.distributed.test.PreviewRepairCoordinatorTimeoutTest):
Caused an ERROR
[junit-timeout]
org.apache.cassandra.distributed.api.NodeToolResult$Asserts.errorContains([Ljava/lang/String;)Lorg/apache/cassandra/distributed/api/NodeToolResult$Asserts;
[junit-timeout] java.lang.NoSuchMethodError:
org.apache.cassandra.distributed.api.NodeToolResult$Asserts.errorContains([Ljava/lang/String;)Lorg/apache/cassandra/distributed/api/NodeToolResult$Asserts;
[junit-timeout] at
org.apache.cassandra.distributed.test.RepairCoordinatorTimeout.lambda$prepareRPCTimeout$0(RepairCoordinatorTimeout.java:45)
[junit-timeout] at
org.apache.cassandra.utils.AssertUtil.lambda$assertTimeoutPreemptively$0(AssertUtil.java:39)
[junit-timeout] at
org.apache.cassandra.utils.AssertUtil.lambda$assertTimeoutPreemptively$1(AssertUtil.java:67)
[junit-timeout] at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit-timeout] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.lang.Thread.run(Thread.java:748)
{code}
Status: Patch Available (was: In Progress)
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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] [Commented] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076236#comment-17076236
]
Massimiliano Tomassi commented on CASSANDRA-15667:
--
PR: [https://github.com/maxtomassi/cassandra/pull/1]
CircleCI:
[https://app.circleci.com/pipelines/github/maxtomassi/cassandra?branch=15667-4.0]
(JVM dtests failed running)
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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] [Assigned] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Tomassi reassigned CASSANDRA-15667:
Assignee: Massimiliano Tomassi (was: Benjamin Lerer)
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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] [Updated] (CASSANDRA-15641) No error if consistency_level = SERIAL and unqualified select
[
https://issues.apache.org/jira/browse/CASSANDRA-15641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Tomassi updated CASSANDRA-15641:
-
Resolution: Invalid
Status: Resolved (was: Open)
> No error if consistency_level = SERIAL and unqualified select
> -
>
> Key: CASSANDRA-15641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15641
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Konstantin
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: test.py
>
>
> The attached test program produces no errors, while doesn't provide serial
> consistency. There is no exception that the consistency level is incorrect.
> It's simply silently downgraded. The issue is not documented either.
> kostja@atlas ~ % python test.py
> Row(a=1, b=1)
> Row(a=0, b=0)
> Row(a=2, b=2)
> Row(a=3, b=3)
> Row(a=1, b=1)
> Row(a=2, b=2)
> The behavior is contrary to the original intent by LWT author, since the code
> has the following check:
>if (group.queries.size() > 1)
> throw new InvalidRequestException("SERIAL/LOCAL_SERIAL
> consistency may only be requested for one partition at a time");
> https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/StorageProxy.java#L1593
--
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] [Commented] (CASSANDRA-15641) No error if consistency_level = SERIAL and unqualified select
[
https://issues.apache.org/jira/browse/CASSANDRA-15641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073535#comment-17073535
]
Massimiliano Tomassi commented on CASSANDRA-15641:
--
Hi [~Osipov], as already explained by [~samt] in the slack channel, the
behaviour depends on how the select statement is implemented. When paging is
turned off, the query you are trying (filtering with an IN clause), results in
a single multi-partition read (in which case the query would fail if SERIAL
consistency is used), while if paging is turned on it will result in separate
single-partition reads each executed with SERIAL consistency, therefore no
exception is thrown.
Here you can see the query failed with paging turned off and SERIAL consistency:
{code:java}
cqlsh> SELECT * FROM test.t where a in (1,2);
InvalidRequest: Error from server: code=2200 [Invalid query]
message="SERIAL/LOCAL_SERIAL consistency may only be requested for one
partition at a time"
{code}
I'm going to close this ticket as it doesn't categorise as a bug.
> No error if consistency_level = SERIAL and unqualified select
> -
>
> Key: CASSANDRA-15641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15641
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Konstantin
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: test.py
>
>
> The attached test program produces no errors, while doesn't provide serial
> consistency. There is no exception that the consistency level is incorrect.
> It's simply silently downgraded. The issue is not documented either.
> kostja@atlas ~ % python test.py
> Row(a=1, b=1)
> Row(a=0, b=0)
> Row(a=2, b=2)
> Row(a=3, b=3)
> Row(a=1, b=1)
> Row(a=2, b=2)
> The behavior is contrary to the original intent by LWT author, since the code
> has the following check:
>if (group.queries.size() > 1)
> throw new InvalidRequestException("SERIAL/LOCAL_SERIAL
> consistency may only be requested for one partition at a time");
> https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/StorageProxy.java#L1593
--
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] [Assigned] (CASSANDRA-15641) No error if consistency_level = SERIAL and unqualified select
[
https://issues.apache.org/jira/browse/CASSANDRA-15641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Tomassi reassigned CASSANDRA-15641:
Assignee: Massimiliano Tomassi
> No error if consistency_level = SERIAL and unqualified select
> -
>
> Key: CASSANDRA-15641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15641
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Konstantin
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: test.py
>
>
> The attached test program produces no errors, while doesn't provide serial
> consistency. There is no exception that the consistency level is incorrect.
> It's simply silently downgraded. The issue is not documented either.
> kostja@atlas ~ % python test.py
> Row(a=1, b=1)
> Row(a=0, b=0)
> Row(a=2, b=2)
> Row(a=3, b=3)
> Row(a=1, b=1)
> Row(a=2, b=2)
> The behavior is contrary to the original intent by LWT author, since the code
> has the following check:
>if (group.queries.size() > 1)
> throw new InvalidRequestException("SERIAL/LOCAL_SERIAL
> consistency may only be requested for one partition at a time");
> https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/StorageProxy.java#L1593
--
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] [Created] (CASSANDRA-14877) StreamCoordinator "leaks" threads
Massimiliano Tomassi created CASSANDRA-14877: Summary: StreamCoordinator "leaks" threads Key: CASSANDRA-14877 URL: https://issues.apache.org/jira/browse/CASSANDRA-14877 Project: Cassandra Issue Type: Bug Components: Streaming and Messaging Reporter: Massimiliano Tomassi Fix For: 2.1.21, 2.2.14, 3.0.18, 3.11.4, 4.0 Since Cassandra 2.1, streaming sessions are started by running a StreamSessionConnector task for each session in a dedicated executor (a static field of StreamCoordinator). That executor is initialized with DebuggableThreadPoolExecutor.createWithFixedPoolSize, which means that once created (up to the given limit of the number of logical cores), its threads are kept alive for Integer.MAX_VALUE seconds. This practically means that once a node needs to establish streaming sessions to n other nodes, it will create Math.min(n, numLogicalCores) StreamConnectionEstablisher threads that will stay parked forever after initializing (not completing) the session. It seems preferable to replace DebuggableThreadPoolExecutor.createWithFixedPoolSize with DebuggableThreadPoolExecutor.createWithMaximumPoolSize which allows providing a saner keep-alive period (e.g. a minute). That's also what createWithFixedPoolSize's Javadoc recommends: If (most) threads are expected to be idle most of the time, prefer createWithMaxSize() instead. -- 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
