[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319968#comment-15319968
]
Chris Lohfink commented on CASSANDRA-7622:
--
May be out of scope of this ticket, but I get nervous when continually
referring to this as "Exposing jmx via cql". Are we referring to creating a new
Reporter for the CassandraMetricsRegistry so all metrics just automagically are
exposed or are we talking about using
{{ManagementFactory.getPlatformMBeanServer()}} and actually reading the mbeans,
having manual process of updating a list of exposed data?
> Implement virtual tables
>
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tupshin Harper
>Assignee: Jeff Jirsa
> Fix For: 3.x
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml
> configuration information. So it would be an alternate approach to
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[ https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-11966: -- Status: Patch Available (was: Open) > When SEPWorker assigned work, set thread name to match pool > --- > > Key: CASSANDRA-11966 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11966 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Attachments: CASSANDRA-11966.patch > > > Currently in traces, logs, and stacktraces you cant really associate the > thread name with the pool since its just "SharedWorker-#". Calling setName > around the task could improve logging and tracing a little while being a > cheap operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[ https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-11966: -- Attachment: CASSANDRA-11966.patch > When SEPWorker assigned work, set thread name to match pool > --- > > Key: CASSANDRA-11966 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11966 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Attachments: CASSANDRA-11966.patch > > > Currently in traces, logs, and stacktraces you cant really associate the > thread name with the pool since its just "SharedWorker-#". Calling setName > around the task could improve logging and tracing a little while being a > cheap operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[
https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319920#comment-15319920
]
Chris Lohfink edited comment on CASSANDRA-11966 at 6/8/16 3:33 AM:
---
An example before/after with patch:
Before:
{code}
activity
--...-+-
... Execute CQL3 query |
... Parsing select * from system.peers; [SharedPool-Worker-1] |
... Preparing statement [SharedPool-Worker-1] |
... Computing ranges to query [SharedPool-Worker-1] |
...y of 1 (403.2 rows per range expected) [SharedPool-Worker-1] |
... Submitted 1 concurrent range requests [SharedPool-Worker-1] |
...854775808), min(-9223372036854775808)) [SharedPool-Worker-2] |
... Read 1 live and 0 tombstone cells [SharedPool-Worker-2] |
...
...Request complete |
{code}
After:
{code}
activity
-...+-
... Execute CQL3 query
|
... Parsing select * from system.peers; [Native-Transport-Requests-2]
|
... Preparing statement [Native-Transport-Requests-2]
|
...Computing ranges to query [Native-Transport-Requests-2]
Subm...ency of 1 (604.8 rows per range expected) [Native-Transport-Requests-2]
|
...Submitted 1 concurrent range requests [Native-Transport-Requests-2]
|
...or (min(-9223372036854775808), min(-9223372036854775808)) [ReadStage-1]
|
...Read 1 live and 0 tombstone cells [ReadStage-1]
|
... Request complete
|
{code}
was (Author: cnlwsu):
An example before/after with patch:
Before:
{code}
activity
|
--...-+-
... Execute CQL3 query |
... Parsing select * from system.peers; [SharedPool-Worker-1] |
... Preparing statement [SharedPool-Worker-1] |
... Computing ranges to query [SharedPool-Worker-1] |
...y of 1 (403.2 rows per range expected) [SharedPool-Worker-1] |
... Submitted 1 concurrent range requests [SharedPool-Worker-1] |
...854775808), min(-9223372036854775808)) [SharedPool-Worker-2] |
... Read 1 live and 0 tombstone cells [SharedPool-Worker-2] |
...
...Request complete |
{code}
After:
{code}
activity
-...+-
... Execute CQL3 query
|
... Parsing select * from system.peers; [Native-Transport-Requests-2]
|
... Preparing statement [Native-Transport-Requests-2]
|
... Computing ranges to query
[Native-Transport-Requests-2]
Subm...ency of 1 (604.8 rows per range expected) [Native-Transport-Requests-2]
|
...Submitted 1 concurrent range requests [Native-Transport-Requests-2]
|
...or (min(-9223372036854775808), min(-9223372036854775808)) [ReadStage-1]
|
...Read 1 live and 0 tombstone cells [ReadStage-1]
|
... Request complete
|
{code}
> When SEPWorker assigned work, set thread name to match pool
> ---
>
> Key: CASSANDRA-11966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11966
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
>
> Currently in traces, logs, and stacktraces you cant really associate the
> thread name with the pool since its just "SharedWorker-#". Calling setName
> around the task could improve logging and tracing a little while being a
> cheap operation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[
https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319920#comment-15319920
]
Chris Lohfink edited comment on CASSANDRA-11966 at 6/8/16 3:31 AM:
---
An example before/after with patch:
Before:
{code}
activity
|
--...-+-
... Execute CQL3 query |
... Parsing select * from system.peers; [SharedPool-Worker-1] |
... Preparing statement [SharedPool-Worker-1] |
... Computing ranges to query [SharedPool-Worker-1] |
...y of 1 (403.2 rows per range expected) [SharedPool-Worker-1] |
... Submitted 1 concurrent range requests [SharedPool-Worker-1] |
...854775808), min(-9223372036854775808)) [SharedPool-Worker-2] |
... Read 1 live and 0 tombstone cells [SharedPool-Worker-2] |
...
...Request complete |
{code}
After:
{code}
activity
-...+-
... Execute CQL3 query
|
... Parsing select * from system.peers; [Native-Transport-Requests-2]
|
... Preparing statement [Native-Transport-Requests-2]
|
... Computing ranges to query
[Native-Transport-Requests-2]
Subm...ency of 1 (604.8 rows per range expected) [Native-Transport-Requests-2]
|
...Submitted 1 concurrent range requests [Native-Transport-Requests-2]
|
...or (min(-9223372036854775808), min(-9223372036854775808)) [ReadStage-1]
|
...Read 1 live and 0 tombstone cells [ReadStage-1]
|
... Request complete
|
{code}
was (Author: cnlwsu):
An example before/after with patch:
Before:
{code}
activity
|
---+-
Execute CQL3 query |
Parsing select *
from system.peers; [SharedPool-Worker-1] |
Preparing statement [SharedPool-Worker-1] |
Computing ranges to query [SharedPool-Worker-1] |
Submitting range requests on 1 ranges with a concurrency of 1 (403.2 rows
per range expected) [SharedPool-Worker-1] |
Submitted 1
concurrent range requests [SharedPool-Worker-1] |
Executing seq scan across 2 sstables for (min(-9223372036854775808),
min(-9223372036854775808)) [SharedPool-Worker-2] |
Read 1 live and
0 tombstone cells [SharedPool-Worker-2] |
Request complete |
{code}
After:
{code}
activity
|
-+-
Execute CQL3 query |
Parsing select *
from system.peers; [Native-Transport-Requests-2] |
Preparing statement [Native-Transport-Requests-2] |
Computing
ranges to query [Native-Transport-Requests-2] |
Submitting range requests on 1 ranges with a concurrency of 1 (604.8 rows per
range expected) [Native-Transport-Requests-2] |
Submitted 1 concurrent
range requests [Native-Transport-Requests-2] |
[jira] [Comment Edited] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[
https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319920#comment-15319920
]
Chris Lohfink edited comment on CASSANDRA-11966 at 6/8/16 3:30 AM:
---
An example before/after with patch:
Before:
{code}
activity
|
---+-
Execute CQL3 query |
Parsing select *
from system.peers; [SharedPool-Worker-1] |
Preparing statement [SharedPool-Worker-1] |
Computing ranges to query [SharedPool-Worker-1] |
Submitting range requests on 1 ranges with a concurrency of 1 (403.2 rows
per range expected) [SharedPool-Worker-1] |
Submitted 1
concurrent range requests [SharedPool-Worker-1] |
Executing seq scan across 2 sstables for (min(-9223372036854775808),
min(-9223372036854775808)) [SharedPool-Worker-2] |
Read 1 live and
0 tombstone cells [SharedPool-Worker-2] |
Request complete |
{code}
After:
{code}
activity
|
-+-
Execute CQL3 query |
Parsing select *
from system.peers; [Native-Transport-Requests-2] |
Preparing statement [Native-Transport-Requests-2] |
Computing
ranges to query [Native-Transport-Requests-2] |
Submitting range requests on 1 ranges with a concurrency of 1 (604.8 rows per
range expected) [Native-Transport-Requests-2] |
Submitted 1 concurrent
range requests [Native-Transport-Requests-2] |
Executing seq scan across 3 sstables for
(min(-9223372036854775808), min(-9223372036854775808)) [ReadStage-1] |
Read 1 live and 0 tombstone cells [ReadStage-1] |
Request complete |
{code}
was (Author: cnlwsu):
An example before/after with patch:
Before:
{code}
activity
| timestamp | source
| source_elapsed | client
---++---++---
Execute CQL3 query | 2016-06-07 22:19:39.982000 | 127.0.0.1
| 0 | 127.0.0.1
Parsing select *
from system.peers; [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2330 | 127.0.0.1
Preparing statement [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2579 | 127.0.0.1
Computing ranges to query [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2825 | 127.0.0.1
Submitting range requests on 1 ranges with a concurrency of 1 (403.2 rows
per range expected) [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2954 | 127.0.0.1
Submitted 1
concurrent range requests [SharedPool-Worker-1] | 2016-06-07 22:19:39.985000 |
127.0.0.1 | 3051 | 127.0.0.1
Executing seq scan across 2 sst
[jira] [Commented] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[
https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319920#comment-15319920
]
Chris Lohfink commented on CASSANDRA-11966:
---
An example before/after with patch:
Before:
{code}
activity
| timestamp | source
| source_elapsed | client
---++---++---
Execute CQL3 query | 2016-06-07 22:19:39.982000 | 127.0.0.1
| 0 | 127.0.0.1
Parsing select *
from system.peers; [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2330 | 127.0.0.1
Preparing statement [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2579 | 127.0.0.1
Computing ranges to query [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2825 | 127.0.0.1
Submitting range requests on 1 ranges with a concurrency of 1 (403.2 rows
per range expected) [SharedPool-Worker-1] | 2016-06-07 22:19:39.984000 |
127.0.0.1 | 2954 | 127.0.0.1
Submitted 1
concurrent range requests [SharedPool-Worker-1] | 2016-06-07 22:19:39.985000 |
127.0.0.1 | 3051 | 127.0.0.1
Executing seq scan across 2 sstables for (min(-9223372036854775808),
min(-9223372036854775808)) [SharedPool-Worker-2] | 2016-06-07 22:19:39.985000 |
127.0.0.1 | 3172 | 127.0.0.1
Read 1 live and
0 tombstone cells [SharedPool-Worker-2] | 2016-06-07 22:19:39.985000 |
127.0.0.1 | 4015 | 127.0.0.1
Request complete | 2016-06-07 22:19:39.986322 | 127.0.0.1
| 4322 | 127.0.0.1
{code}
After:
{code}
activity
| timestamp |
source| source_elapsed | client
-++---++---
Execute CQL3 query | 2016-06-07 22:24:59.502000 |
127.0.0.1 | 0 | 127.0.0.1
Parsing select *
from system.peers; [Native-Transport-Requests-2] | 2016-06-07 22:24:59.503000 |
127.0.0.1 | 1848 | 127.0.0.1
Preparing statement [Native-Transport-Requests-2] | 2016-06-07 22:24:59.503000
| 127.0.0.1 | 2090 | 127.0.0.1
Computing
ranges to query [Native-Transport-Requests-2] | 2016-06-07 22:24:59.503000 |
127.0.0.1 | 2396 | 127.0.0.1
Submitting range requests on 1 ranges with a concurrency of 1 (604.8 rows per
range expected) [Native-Transport-Requests-2] | 2016-06-07 22:24:59.504000 |
127.0.0.1 | 2546 | 127.0.0.1
Submitted 1 concurrent
range requests [Native-Transport-Requests-2] | 2016-06-07 22:24:59.504000 |
127.0.0.1 | 2650 | 127.0.0.1
Executing seq scan across 3 sstables for
(min(-9223372036854775808), min(-9223372036854775808)) [ReadStage-1] |
2016-06-07 22:24:59.504000 | 127.0.0.1 | 2751 | 127.0.0.1
Read 1 live and 0 tombstone cells [ReadStage-1] | 2016-06-07 22:24:59.505000 |
127.0.0.1 | 3656 | 127.0.0.1
Request complete | 2016-06-07 22:24:59.506012 |
127.0.0.1 | 4012 | 127.0.0.1
{code}
> When SEPWorker assigned work, set thread name to match pool
> ---
>
> Key: CASSANDRA-11966
>
[jira] [Created] (CASSANDRA-11975) dtest failure in json_tools_test.TestJson.json_tools_test
Craig Kodman created CASSANDRA-11975: Summary: dtest failure in json_tools_test.TestJson.json_tools_test Key: CASSANDRA-11975 URL: https://issues.apache.org/jira/browse/CASSANDRA-11975 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-2.2_dtest_win32/252/testReport/json_tools_test/TestJson/json_tools_test Failed on CassCI build cassandra-2.2_dtest_win32 #252 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319696#comment-15319696 ] Tupshin Harper commented on CASSANDRA-7622: --- +1 from me. I just wanted to make sure that write support would stay on the short term road map. Fine staging it that way. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319575#comment-15319575 ] Jeremiah Jordan commented on CASSANDRA-7622: Sounds like a good implementation plan to me. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11928) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319565#comment-15319565
]
Tyler Hobbs commented on CASSANDRA-11928:
-
I think one step we could take to make tests that utilize tracing less flaky is
to add a system flag to make trace writes synchronous and at {{CL.ALL}} instead
of async and {{CL.ANY}}.
> dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
>
>
> Key: CASSANDRA-11928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11928
> Project: Cassandra
> Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Tyler Hobbs
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/727/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test
> Failed on CassCI build cassandra-3.0_dtest #727
> Is it a problem that the tracing message with the query is missing?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319540#comment-15319540 ] Sylvain Lebresne commented on CASSANDRA-7622: - Yep :). I started answering to Tupshin and saw your comment update and copy-pasted the beginning without really reading till the end. Mea culpa. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319514#comment-15319514 ] Jon Haddad commented on CASSANDRA-7622: --- So... exactly what I said? :) > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319507#comment-15319507 ] Sylvain Lebresne commented on CASSANDRA-7622: - bq. we'll want to be able to write to those tables as well I never said we wouldn't allow that, just that exposing metrics read-only is a viable first version and want to start with that. Allowing writing would certainly be step 2, and that would likely come pretty quickly after step 1 (who knows, it might even make the same version than step 1), but you have to update different parts to get writes and so it's imo simpler (for the author and the reviewer) to split that part up. In other words, I think doing read-only first and adding writes seconds is more incremental technically, and I don't think it's a big deal if we get read-only in say 3.10 and only allow writing in say 3.12. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319504#comment-15319504
]
Tyler Hobbs commented on CASSANDRA-10786:
-
I could be missing something, but it seems like auto server-side preparation
might cause problems for v3/v4 clients. Our current invalidation isn't perfect
(hence the reason for this ticket), but it does help in some cases. Perhaps if
we could try to automatically re-prepare server-side, but only if the result
set metadata doesn't change? We would also need to make sure we handle errors
during preparation gracefully, which might happen if a table, column, or index
is dropped.
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319499#comment-15319499 ] Jon Haddad edited comment on CASSANDRA-7622 at 6/7/16 9:42 PM: --- I agree with [~tupshin] that we'll want to be able to write to those tables as well, but I'd rather see a first cut in a tick tock release of read only tables, then a follow up 2 months later with writes, rather than having to wait for the whole thing. Getting access to metrics in a read only, non JMX fashion would be awesome from an operational perspective and be 100% worth it by itself. I also +1 that it's totally fine to avoid thinking about replication. was (Author: rustyrazorblade): I agree with [~tupshin] that we'll want to be able to write to those tables as well, but I'd rather see a first cut in a tick tock release of read only tables, then a follow up 2 months later with writes, rather than having to wait for the whole thing. Getting access to metrics in a read only, non JMX fashion would be awesome from an operational perspective and be 100% worth it by itself. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319499#comment-15319499 ] Jon Haddad commented on CASSANDRA-7622: --- I agree with [~tupshin] that we'll want to be able to write to those tables as well, but I'd rather see a first cut in a tick tock release of read only tables, then a follow up 2 months later with writes, rather than having to wait for the whole thing. Getting access to metrics in a read only, non JMX fashion would be awesome from an operational perspective and be 100% worth it by itself. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8700) replace the wiki with docs in the git repo
[
https://issues.apache.org/jira/browse/CASSANDRA-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319498#comment-15319498
]
Sylvain Lebresne commented on CASSANDRA-8700:
-
{quote}
I've gotten access to manage our old confluence wiki from CASSANDRA-145
https://cwiki.apache.org/confluence/display/CSDR/Index
{quote}
You'll have to tell me how your managed that. I naively though using the INFRA
jira would be a good way but apparently not:
https://issues.apache.org/jira/browse/INFRA-10942.
bq. having the committers bottlenecked on docs might be problematic.
I _strongly_ doubt this would happen and I kind of would love for that to
happen. We have had our CQL doc in tree for a while now, and that hasn't even
remotely be a problem. Besides, I haven't doc an extensive study of the
question, but I suspect the doc of most open source project is primarily
written by the main contributor of said project, which really kind of make
sense.
Truly, I see 2 big advantages to having the doc in-tree:
# this makes it easier for us to keep the doc up-to-date: if a ticket changes
something that impact documentation, including the change in the patch is a lot
easier that not forgetting to go update some wiki when the patch gets committed.
# this guarantees the documentation is somewhat reviewed. Imo, that's actually
important.
So, me very much in favor of having the doc in-tree, and I plan on taking some
time in next few days to setting something up.
> replace the wiki with docs in the git repo
> --
>
> Key: CASSANDRA-8700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8700
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Sylvain Lebresne
>Priority: Minor
>
> The wiki as it stands is pretty terrible. It takes several minutes to apply
> a single update, and as a result, it's almost never updated. The information
> there has very little context as to what version it applies to. Most people
> I've talked to that try to use the information they find there find it is
> more confusing than helpful.
> I'd like to propose that instead of using the wiki, the doc directory in the
> cassandra repo be used for docs (already used for CQL3 spec) in a format that
> can be built to a variety of output formats like HTML / epub / etc. I won't
> start the bikeshedding on which markup format is preferable - but there are
> several options that can work perfectly fine. I've personally use sphinx w/
> restructured text, and markdown. Both can build easily and as an added bonus
> be pushed to readthedocs (or something similar) automatically. For an
> example, see cqlengine's documentation, which I think is already
> significantly better than the wiki:
> http://cqlengine.readthedocs.org/en/latest/
> In addition to being overall easier to maintain, putting the documentation in
> the git repo adds context, since it evolves with the versions of Cassandra.
> If the wiki were kept even remotely up to date, I wouldn't bother with this,
> but not having at least some basic documentation in the repo, or anywhere
> associated with the project, is frustrating.
> For reference, the last 3 updates were:
> 1/15/15 - updating committers list
> 1/08/15 - updating contributers and how to contribute
> 12/16/14 - added a link to CQL docs from wiki frontpage (by me)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319483#comment-15319483 ] Tupshin Harper commented on CASSANDRA-7622: --- As the filer of this ticket, I largely agree about the scope issue. I was surprised to see any notion of replication being discussed, because I didn't view persistence or cross-node awareness/aggregation as being a feature of virtual tables. I do think that exposing JMX provides the best initial use case, and would like to target that first. The higher level interface that Sylvain proposes is also very much in the right direction. That said, I disagree with one aspect. There's no reason to restrict the API to read only, even initially. Most JMX metrics are read only, and those would either be ignore, or raise an error, if they were attempted to be written to. But JMX metrix that arer settable, should be exposable as r/w (with separate read vs write permissions, of course). If an interface is designed sufficient to allow the elegant reading and writing of jmx metrics, it will be widely usable for many other plugins/virtual tables as well. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8700) replace the wiki with docs in the git repo
[ https://issues.apache.org/jira/browse/CASSANDRA-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-8700: --- Assignee: Sylvain Lebresne > replace the wiki with docs in the git repo > -- > > Key: CASSANDRA-8700 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8700 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Jon Haddad >Assignee: Sylvain Lebresne >Priority: Minor > > The wiki as it stands is pretty terrible. It takes several minutes to apply > a single update, and as a result, it's almost never updated. The information > there has very little context as to what version it applies to. Most people > I've talked to that try to use the information they find there find it is > more confusing than helpful. > I'd like to propose that instead of using the wiki, the doc directory in the > cassandra repo be used for docs (already used for CQL3 spec) in a format that > can be built to a variety of output formats like HTML / epub / etc. I won't > start the bikeshedding on which markup format is preferable - but there are > several options that can work perfectly fine. I've personally use sphinx w/ > restructured text, and markdown. Both can build easily and as an added bonus > be pushed to readthedocs (or something similar) automatically. For an > example, see cqlengine's documentation, which I think is already > significantly better than the wiki: > http://cqlengine.readthedocs.org/en/latest/ > In addition to being overall easier to maintain, putting the documentation in > the git repo adds context, since it evolves with the versions of Cassandra. > If the wiki were kept even remotely up to date, I wouldn't bother with this, > but not having at least some basic documentation in the repo, or anywhere > associated with the project, is frustrating. > For reference, the last 3 updates were: > 1/15/15 - updating committers list > 1/08/15 - updating contributers and how to contribute > 12/16/14 - added a link to CQL docs from wiki frontpage (by me) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7622) Implement virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319451#comment-15319451
]
Sylvain Lebresne commented on CASSANDRA-7622:
-
I really think we should approach this in a more restricted way first, and
would *strongly* prefer we do so. I think initially virtual tables should be a
purely internal mechanism that we use for:
# exposing metrics for those alergic to JMX
# exposing more of the replica state (some of which is already exposed in our
existing system tables) when it makes sense. We might also have a few system
table that don't really rely on persistence and could be switched to virtual
tables for their implementation.
I'm not saying this is the only possible use case for virtual tables, but
that's the main use case that has brought so far and it's a pretty damn good
start.
That does mean starting with read-only tables, no CQL syntax for creating
random virtual table for now (if I'm being honest, I'm not yet convinced we
should ever add it) and probably sticking to local (non replicated) tables for
now. And I think there is enough to discuss for such initial version that it's
worth leaving the discussing for further extension to later. In particular,
that still leave discussion on:
# how do we implement that
# what do we initially expose with this and how (typically, for metrics, what
schema are we going for).
I'll note that on the implementation front, I think the cleanest and simplest
solution might be to expose such virtual table as some fake memtable that is
never flushed. That is, as far as reading is concerned, a memtable mostly
expose 2 methods:
{noformat}
UnfilteredPartitionIterator makePartitionIterator(ColumnFilter columnFilter,
DataRange dataRange, boolean isForThrift)
Partition getPartition(DecoratedKey key)
{noformat}
and that's what virtual tables would have to implement in general.
Of course, in practice, we wouldn't want to re-implement such fairly generic
method for every new virtual table. So I imagine we could create some form of
"builder" that would allow to declare each column of the virtual table and
associate to each column a callback, used to compute the value. As well as
method to iterate over which rows the table has. So something like this (not at
all refine, just to give a clearer idea of what I mean):
{noformat}
public interface VirtualTableBuilder
{
/**
* Adds column {@code name} with type {@code type} to the virtual table.
The value
* for that column is computed using {@code callback}.
*/
public void add(ColumnIdentifier name, AbstractType type, Callback
callback);
/**
* Returns an iterator generating the partition keys of the virtual table.
*/
public Iterator partitionKeys();
/**
* Given a particular partition key, returns an iterator generating the
rows contained
* in this keys of the virtual table.
*/
public Iterator clusterings(DecoratedKey key);
public interface Callback
{
/**
* Computes a column value given the primary key to that column.
*/
public ByteBuffer compute(DecoratedKey partitionKey, Clustering
clustering);
}
}
{noformat}
Given this, we should be able to generate a proper "VirtualMemtable" object I
describe above.
bq. So at least for the things I can think of the "nicest" interface would be
that virtual tables have some kind of "where should I get routed" function, so
you could do custom routing.
I admit the idea of being able to query a given metrics for the whole cluster
in a single query is seducing on paper, but I'm not at all sure it's actually a
good idea. Queries that rely on all the nodes of the cluster responding to
return sounds bad to me. Even if we were to handle timeouts differently, still
returning a result but with just no results for the nodes that didn't answered,
I assume having the collection of all your metrics blocked for X seconds due to
a single node is strictly worth for monitoring system than querying nodes
themselves and thus have only the metrics to the node that are unhealthy be
delayed.
Overall, feels like a lot of complexity on our side for doubtful usefulness.
> Implement virtual tables
>
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tupshin Harper
>Assignee: Jeff Jirsa
> Fix For: 3.x
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement t
[jira] [Commented] (CASSANDRA-11974) Failed assert causes OutboundTcpConnection to exit
[
https://issues.apache.org/jira/browse/CASSANDRA-11974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319443#comment-15319443
]
sankalp kohli commented on CASSANDRA-11974:
---
Along with fixing the underlining issue, we should also do
https://issues.apache.org/jira/browse/CASSANDRA-8114
> Failed assert causes OutboundTcpConnection to exit
> --
>
> Key: CASSANDRA-11974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11974
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Sean Thornton
>
> I am seeing the following in a client's cluster:
> {noformat}
> ERROR [MessagingService-Outgoing-/10.0.0.1] 2016-06-06 03:38:19,305
> CassandraDaemon.java:229 - Exception in thread
> Thread[MessagingService-Outgoing-/10.0.0.1,5,main]
> java.lang.AssertionError: 635174
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:392)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:381)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:271)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:259)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:503)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:490)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.SliceFromReadCommandSerializer.serialize(SliceFromReadCommand.java:168)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:143)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:132)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:121)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:330)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:282)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:218)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> {noformat}
> Obviously they somehow exceeded a 64K limit (quick and dirty suspects -
> https://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html) but
> that is neither here nor there.
> The problem I see when this happens is
> {{ByteBufferUtil.writeWithShortLength}} can throw a
> {{java.lang.AssertionError}} which is a true {{Error}} that bubbles up and
> totally bypasses the {{catch (Exception e)}} clause in the message processing
> loop in {{OutboundTcpConnection.run()}} _which causes the thread to exit and
> that node to no longer communicate outgoing messages to other nodes_.
> At least from my perspective, there are two things I would like to see
> handled differently -
> * In the event of _any_ problem, I would like to see whatever details
> possible be logged about the problem Message - partition key, CF data,
> anything. Right now it can be very difficult to track this down
> * The {{java.lang.Error}} possibility needs to be handled somehow. If it's
> an assertion error, it seems like we could continue the processing loop. But
> shutting down the JVM would be better than what I get now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11974) Failed assert causes OutboundTcpConnection to exit
Sean Thornton created CASSANDRA-11974:
-
Summary: Failed assert causes OutboundTcpConnection to exit
Key: CASSANDRA-11974
URL: https://issues.apache.org/jira/browse/CASSANDRA-11974
Project: Cassandra
Issue Type: Bug
Components: Streaming and Messaging
Reporter: Sean Thornton
I am seeing the following in a client's cluster:
{noformat}
ERROR [MessagingService-Outgoing-/10.0.0.1] 2016-06-06 03:38:19,305
CassandraDaemon.java:229 - Exception in thread
Thread[MessagingService-Outgoing-/10.0.0.1,5,main]
java.lang.AssertionError: 635174
at
org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:392)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:381)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:271)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:259)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:503)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:490)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.SliceFromReadCommandSerializer.serialize(SliceFromReadCommand.java:168)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:143)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:132)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:121)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:330)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:282)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:218)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
{noformat}
Obviously they somehow exceeded a 64K limit (quick and dirty suspects -
https://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html) but that
is neither here nor there.
The problem I see when this happens is {{ByteBufferUtil.writeWithShortLength}}
can throw a {{java.lang.AssertionError}} which is a true {{Error}} that bubbles
up and totally bypasses the {{catch (Exception e)}} clause in the message
processing loop in {{OutboundTcpConnection.run()}} _which causes the thread to
exit and that node to no longer communicate outgoing messages to other nodes_.
At least from my perspective, there are two things I would like to see handled
differently -
* In the event of _any_ problem, I would like to see whatever details possible
be logged about the problem Message - partition key, CF data, anything. Right
now it can be very difficult to track this down
* The {{java.lang.Error}} possibility needs to be handled somehow. If it's an
assertion error, it seems like we could continue the processing loop. But
shutting down the JVM would be better than what I get now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8700) replace the wiki with docs in the git repo
[ https://issues.apache.org/jira/browse/CASSANDRA-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319336#comment-15319336 ] Jonathan Ellis commented on CASSANDRA-8700: --- Here is my outline: Index.html - Suggest flat directory structure (index.html, cql.html, gettingstarted.html, etc) - Update generate-cql-html in build.xml to build everything Getting Started - Installation (Can follow Wiki reasonably closely) - Cqlsh Data Modeling / CQL - Existing doc is good, just including for completeness Operating Cassandra (can follow wiki but update as appropriate, e.g. we can assume vnodes by default now) - ReplicationStrategy - Adding and removing nodes - Repair - Compaction + Size Tiered + Leveled + TimeWindow - Leave out soon-to-be-deprecated DateTiered - Tombstones and gcgs - Backups - Monitoring - Nodetool (Can we autogenerate this from Nodetool’s help?) Troubleshooting - GCInspector and SystemLogger + tpstats FAQ - Limitations > replace the wiki with docs in the git repo > -- > > Key: CASSANDRA-8700 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8700 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Jon Haddad >Priority: Minor > > The wiki as it stands is pretty terrible. It takes several minutes to apply > a single update, and as a result, it's almost never updated. The information > there has very little context as to what version it applies to. Most people > I've talked to that try to use the information they find there find it is > more confusing than helpful. > I'd like to propose that instead of using the wiki, the doc directory in the > cassandra repo be used for docs (already used for CQL3 spec) in a format that > can be built to a variety of output formats like HTML / epub / etc. I won't > start the bikeshedding on which markup format is preferable - but there are > several options that can work perfectly fine. I've personally use sphinx w/ > restructured text, and markdown. Both can build easily and as an added bonus > be pushed to readthedocs (or something similar) automatically. For an > example, see cqlengine's documentation, which I think is already > significantly better than the wiki: > http://cqlengine.readthedocs.org/en/latest/ > In addition to being overall easier to maintain, putting the documentation in > the git repo adds context, since it evolves with the versions of Cassandra. > If the wiki were kept even remotely up to date, I wouldn't bother with this, > but not having at least some basic documentation in the repo, or anywhere > associated with the project, is frustrating. > For reference, the last 3 updates were: > 1/15/15 - updating committers list > 1/08/15 - updating contributers and how to contribute > 12/16/14 - added a link to CQL docs from wiki frontpage (by me) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[ https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink reassigned CASSANDRA-11966: - Assignee: Chris Lohfink > When SEPWorker assigned work, set thread name to match pool > --- > > Key: CASSANDRA-11966 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11966 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > > Currently in traces, logs, and stacktraces you cant really associate the > thread name with the pool since its just "SharedWorker-#". Calling setName > around the task could improve logging and tracing a little while being a > cheap operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11973) Is MemoryUtil.getShort() supposed to return a sign-extended or non-sign-extended value?
[ https://issues.apache.org/jira/browse/CASSANDRA-11973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rei Odaira updated CASSANDRA-11973: --- Flags: Patch Attachment: 11973-2.2.txt > Is MemoryUtil.getShort() supposed to return a sign-extended or > non-sign-extended value? > --- > > Key: CASSANDRA-11973 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11973 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Rei Odaira >Assignee: Rei Odaira >Priority: Minor > Fix For: 2.2.x, 3.0.x, 3.x > > Attachments: 11973-2.2.txt > > > In org.apache.cassandra.utils.memory.MemoryUtil.getShort(), the returned > value of unsafe.getShort(address) is bit-wise-AND'ed with 0x, while that > of getShortByByte(address) is not. This inconsistency results in different > returned values when the short integer is negative. Which is preferred > behavior? Looking at NativeClustering and NativeCellTest, it seems like > non-sign-extension is assumed. > By the way, is there any reason MemoryUtil.getShort() and > MemoryUtil.getShortByByte() return "int", not "short"? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11973) Is MemoryUtil.getShort() supposed to return a sign-extended or non-sign-extended value?
Rei Odaira created CASSANDRA-11973: -- Summary: Is MemoryUtil.getShort() supposed to return a sign-extended or non-sign-extended value? Key: CASSANDRA-11973 URL: https://issues.apache.org/jira/browse/CASSANDRA-11973 Project: Cassandra Issue Type: Bug Components: Core Reporter: Rei Odaira Assignee: Rei Odaira Priority: Minor Fix For: 2.2.x, 3.0.x, 3.x In org.apache.cassandra.utils.memory.MemoryUtil.getShort(), the returned value of unsafe.getShort(address) is bit-wise-AND'ed with 0x, while that of getShortByByte(address) is not. This inconsistency results in different returned values when the short integer is negative. Which is preferred behavior? Looking at NativeClustering and NativeCellTest, it seems like non-sign-extension is assumed. By the way, is there any reason MemoryUtil.getShort() and MemoryUtil.getShortByByte() return "int", not "short"? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11972) Use byte[] instead of object tree in Frame.Header
[
https://issues.apache.org/jira/browse/CASSANDRA-11972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318998#comment-15318998
]
Sylvain Lebresne commented on CASSANDRA-11972:
--
I will note that while removing allocations is a worthy goal, this will only
remove those couple of allocations per-native-transport-message, which is not
necessarily a big deal, and this probably at the cost of some code clarity.
Now, it's probable in this case that the code clarity should suffer much, but I
guess my point is that we should take the habit of trying to demonstrate the
benefits of that kind of patch, or it's really premature optimization.
> Use byte[] instead of object tree in Frame.Header
> -
>
> Key: CASSANDRA-11972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11972
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Replacing the object tree/references in {{Frame.Header}} with {{byte[9]}}
> saves a couple of object allocations. Also, not allocating the 9 bytes for
> the header off-heap is less expensive.
> (will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11919) Failure in nodetool decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-11919:
Reproduced In: 2.2.4
> Failure in nodetool decommission
>
>
> Key: CASSANDRA-11919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11919
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: Centos 6.6 x86_64, Cassandra 2.2.4
>Reporter: vin01
>Priority: Minor
> Fix For: 2.2.x
>
>
> I keep getting an exception while attempting "nodetool decommission".
> {code}
> ERROR [STREAM-IN-/[NODE_ON_WHICH_DECOMMISSION_RUNNING]] 2016-05-29
> 13:08:39,040 StreamSession.java:524 - [Stream
> #b2039080-25c2-11e6-bd92-d71331aaf180] Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> {code}
> Because of these, decommission process is not succeeding.
> Is interrupting the decommission process safe? Seems like i will have to
> retry to make it work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11919) Failure in nodetool decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-11919: Fix Version/s: 2.2.x > Failure in nodetool decommission > > > Key: CASSANDRA-11919 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11919 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging > Environment: Centos 6.6 x86_64, Cassandra 2.2.4 >Reporter: vin01 >Priority: Minor > Fix For: 2.2.x > > > I keep getting an exception while attempting "nodetool decommission". > ERROR [STREAM-IN-/[NODE_ON_WHICH_DECOMMISSION_RUNNING]] 2016-05-29 > 13:08:39,040 StreamSession.java:524 - [Stream > #b2039080-25c2-11e6-bd92-d71331aaf180] Streaming error occurred > java.lang.IllegalArgumentException: Unknown type 0 > at > org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96) > ~[apache-cassandra-2.2.4.jar:2.2.4] > at > org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57) > ~[apache-cassandra-2.2.4.jar:2.2.4] > at > org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261) > ~[apache-cassandra-2.2.4.jar:2.2.4] > Because of these, decommission process is not succeeding. > Is interrupting the decommission process safe? Seems like i will have to > retry to make it work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11919) Failure in nodetool decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-11919:
Description:
I keep getting an exception while attempting "nodetool decommission".
{code}
ERROR [STREAM-IN-/[NODE_ON_WHICH_DECOMMISSION_RUNNING]] 2016-05-29 13:08:39,040
StreamSession.java:524 - [Stream #b2039080-25c2-11e6-bd92-d71331aaf180]
Streaming error occurred
java.lang.IllegalArgumentException: Unknown type 0
at
org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
~[apache-cassandra-2.2.4.jar:2.2.4]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
~[apache-cassandra-2.2.4.jar:2.2.4]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
~[apache-cassandra-2.2.4.jar:2.2.4]
{code}
Because of these, decommission process is not succeeding.
Is interrupting the decommission process safe? Seems like i will have to retry
to make it work.
was:
I keep getting an exception while attempting "nodetool decommission".
ERROR [STREAM-IN-/[NODE_ON_WHICH_DECOMMISSION_RUNNING]] 2016-05-29 13:08:39,040
StreamSession.java:524 - [Stream #b2039080-25c2-11e6-bd92-d71331aaf180]
Streaming error occurred
java.lang.IllegalArgumentException: Unknown type 0
at
org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
~[apache-cassandra-2.2.4.jar:2.2.4]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
~[apache-cassandra-2.2.4.jar:2.2.4]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
~[apache-cassandra-2.2.4.jar:2.2.4]
Because of these, decommission process is not succeeding.
Is interrupting the decommission process safe? Seems like i will have to retry
to make it work.
> Failure in nodetool decommission
>
>
> Key: CASSANDRA-11919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11919
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: Centos 6.6 x86_64, Cassandra 2.2.4
>Reporter: vin01
>Priority: Minor
> Fix For: 2.2.x
>
>
> I keep getting an exception while attempting "nodetool decommission".
> {code}
> ERROR [STREAM-IN-/[NODE_ON_WHICH_DECOMMISSION_RUNNING]] 2016-05-29
> 13:08:39,040 StreamSession.java:524 - [Stream
> #b2039080-25c2-11e6-bd92-d71331aaf180] Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> {code}
> Because of these, decommission process is not succeeding.
> Is interrupting the decommission process safe? Seems like i will have to
> retry to make it work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11972) Use byte[] instead of object tree in Frame.Header
Robert Stupp created CASSANDRA-11972:
Summary: Use byte[] instead of object tree in Frame.Header
Key: CASSANDRA-11972
URL: https://issues.apache.org/jira/browse/CASSANDRA-11972
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
Fix For: 3.x
Replacing the object tree/references in {{Frame.Header}} with {{byte[9]}} saves
a couple of object allocations. Also, not allocating the 9 bytes for the header
off-heap is less expensive.
(will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11971) More uses of DataOutputBuffer.RECYCLER
Robert Stupp created CASSANDRA-11971:
Summary: More uses of DataOutputBuffer.RECYCLER
Key: CASSANDRA-11971
URL: https://issues.apache.org/jira/browse/CASSANDRA-11971
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
Fix For: 3.x
There are a few more possible use cases for {{DataOutputBuffer.RECYCLER}},
which prevents a couple of (larger) allocations.
(Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11970) Reuse DataOutputBuffer from ColumnIndex
Robert Stupp created CASSANDRA-11970:
Summary: Reuse DataOutputBuffer from ColumnIndex
Key: CASSANDRA-11970
URL: https://issues.apache.org/jira/browse/CASSANDRA-11970
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
Fix For: 3.x
With a simple change, the {{DataOutputBuffer}} used in {{ColumnIndex}} can be
reused. This saves a couple of (larger) object allocations.
(Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11969) Prevent duplicate ctx.channel().attr() call
[
https://issues.apache.org/jira/browse/CASSANDRA-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11969:
-
Fix Version/s: 3.x
> Prevent duplicate ctx.channel().attr() call
> ---
>
> Key: CASSANDRA-11969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11969
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
>
> In {{Frame}} we can save one call to
> {{ctx.channel().attr(Connection.attributeKey)}}.
> (Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11969) Prevent duplicate ctx.channel().attr() call
Robert Stupp created CASSANDRA-11969:
Summary: Prevent duplicate ctx.channel().attr() call
Key: CASSANDRA-11969
URL: https://issues.apache.org/jira/browse/CASSANDRA-11969
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Trivial
In {{Frame}} we can save one call to
{{ctx.channel().attr(Connection.attributeKey)}}.
(Will provide a patch soon)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11968) More metrics on native protocol requests & responses
Robert Stupp created CASSANDRA-11968: Summary: More metrics on native protocol requests & responses Key: CASSANDRA-11968 URL: https://issues.apache.org/jira/browse/CASSANDRA-11968 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Assignee: Robert Stupp Priority: Minor Fix For: 3.x Proposal to add more metrics to the native protocol: - number of requests per request-type - number of responses by response-type - size of request messages in bytes - size of response messages in bytes - number of in-flight requests (from request arrival to response) (Will provide a patch soon) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11967) Export metrics for prometheus in its native format
Robert Stupp created CASSANDRA-11967: Summary: Export metrics for prometheus in its native format Key: CASSANDRA-11967 URL: https://issues.apache.org/jira/browse/CASSANDRA-11967 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Assignee: Robert Stupp Priority: Minor Fix For: 3.x https://github.com/snazy/prometheus-metrics-exporter allows to export codahale metrics for prometheus.io. In order to integrate this, a minor change to C* is necessary to load the library. This eliminates the need to use the additional graphite-exporter tool and therefore also allows prometheus to track the up/down status of C*. (Will provide the patch soon) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
[ https://issues.apache.org/jira/browse/CASSANDRA-11966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318890#comment-15318890 ] Robert Stupp commented on CASSANDRA-11966: -- Yup - during runtime, it's a cheap operation. This is a nice improvement - mind providing a patch? Just please add a system property to be able to turn this feature off - some profilers get crazy when you change thread names. > When SEPWorker assigned work, set thread name to match pool > --- > > Key: CASSANDRA-11966 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11966 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Chris Lohfink >Priority: Minor > > Currently in traces, logs, and stacktraces you cant really associate the > thread name with the pool since its just "SharedWorker-#". Calling setName > around the task could improve logging and tracing a little while being a > cheap operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11963) Paged queries limited to Integer.MAX_VALUE total rows
[
https://issues.apache.org/jira/browse/CASSANDRA-11963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318886#comment-15318886
]
Sylvain Lebresne commented on CASSANDRA-11963:
--
Appears my brain wasn't fully functional on my previous comment.
{{PagingState.remaining}} is about how much row should be returned before
hitting your global (query) limit. That is, if you do {{SELECT ... LIMIT
1}}, we need to keep track of where we are of that {{1}} limit somehow
and it can't be reset. Now, the part I brain-farted is that this limit is
really not related to paging, it just happen that we currently use an {{int}}
for the query {{LIMIT}} and thus are limited to {{Integer.MAX_INT}} paging or
no paging.
Now, when the use do set a {{LIMIT}}, I don't think the {{Integer.MAX_INT}}
limit is a huge deal, and while we should probably still switch to a {{long}}
in the long run (which should be doable on trunk since "I think" we use vints
everywhere it matters), it's probably fine to keep that limitation in 2.1/2.2.
What we should fix though is when users don't {{LIMIT}} the query. In that
case, we currently use {{Integer.MAX_INT}} but don't special case more than
that, which mean we effectively silently limit the query and that's not great.
So we should special case {{Integer.MAX_INT}} in the paging code to really mean
no limit and have it act like so (in which case we can indeed do so in 2.1/2.2
since in that case we'll basically ignore {{PagingState.remaining}} and can
have it be {{Integer.MAX_INT}} on every page). For 3.0 though, we can probably
just stick with switching to a {{long}} for the limit and
{{PagingState.remaining}} (assuming I'm not missing a reason why we can't do
so).
> Paged queries limited to Integer.MAX_VALUE total rows
> -
>
> Key: CASSANDRA-11963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11963
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Adam Holmberg
>Priority: Minor
> Fix For: 2.1.x, 2.2.x
>
>
> Paged queries are artificially limited to Integer.MAX_INT rows in total. This
> appears to be related to PagingState.remaining, which decrements
> monotonically as pages are consumed.
> I don't think this is intentional behavior, and haven't found any mention of
> it in the docs.
> Issue observed in latest 2.1 and 2.2 releases. Does not occur in 3.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11966) When SEPWorker assigned work, set thread name to match pool
Chris Lohfink created CASSANDRA-11966: - Summary: When SEPWorker assigned work, set thread name to match pool Key: CASSANDRA-11966 URL: https://issues.apache.org/jira/browse/CASSANDRA-11966 Project: Cassandra Issue Type: Improvement Components: Observability Reporter: Chris Lohfink Priority: Minor Currently in traces, logs, and stacktraces you cant really associate the thread name with the pool since its just "SharedWorker-#". Calling setName around the task could improve logging and tracing a little while being a cheap operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11841) Add keep-alive to stream protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-11841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318862#comment-15318862
]
Yuki Morishita commented on CASSANDRA-11841:
Thanks for the patch. Overall it seems good.
One thing to point out is I thing we should {{setRemoveOnCancelPolicy(true)}}
on {{keepAliveExecutor}} otherwise the task may send keep alive to already
closed connection.
Can you run tests again, since it seems they were not running properly?
> Add keep-alive to stream protocol
> -
>
> Key: CASSANDRA-11841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11841
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11963) Paged queries limited to Integer.MAX_VALUE total rows
[ https://issues.apache.org/jira/browse/CASSANDRA-11963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318823#comment-15318823 ] Adam Holmberg edited comment on CASSANDRA-11963 at 6/7/16 4:35 PM: --- This is not a huge concern to me (scans like this can be broken up using token()), but just for the sake of discussion, is there any reason PagingState.remaining could just be reset for each page of the query? That seems to be the behavior in 3.0. It wouldn't require any change in format, and there was never any client contract on the semantics of those parts. Most clients of which I'm aware treat them as opaque blobs. Also, I don't think that changes the PagingState semantics from a server cursor perspective -- it just removes the stopping condition. was (Author: aholmber): This is not a huge concern to me (scans like this can be broken up using token()), but just for the sake of discussion, is there any reason PagingState.remaining could just be reset for each page of the query? That seems to be the behavior in 3.0. It wouldn't require any change in format, and there was never any client contract on the semantics of those parts. Most clients of which I'm aware treat them as opaque blobs. Also, I don't think that changes the PagingState semantics from a server cursor perspective -- it just removes the limitation. > Paged queries limited to Integer.MAX_VALUE total rows > - > > Key: CASSANDRA-11963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11963 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Holmberg >Priority: Minor > Fix For: 2.1.x, 2.2.x > > > Paged queries are artificially limited to Integer.MAX_INT rows in total. This > appears to be related to PagingState.remaining, which decrements > monotonically as pages are consumed. > I don't think this is intentional behavior, and haven't found any mention of > it in the docs. > Issue observed in latest 2.1 and 2.2 releases. Does not occur in 3.x -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11963) Paged queries limited to Integer.MAX_VALUE total rows
[ https://issues.apache.org/jira/browse/CASSANDRA-11963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318823#comment-15318823 ] Adam Holmberg commented on CASSANDRA-11963: --- This is not a huge concern to me (scans like this can be broken up using token()), but just for the sake of discussion, is there any reason PagingState.remaining could just be reset for each paged of the query? That seems to be the behavior in 3.0. It wouldn't require any change in format, and there was never any client contract on the semantics of those parts. Most clients of which I'm aware treat them as opaque blobs. Also, I don't think that changes the PagingState semantics from a server cursor perspective -- it just removes the limitation. > Paged queries limited to Integer.MAX_VALUE total rows > - > > Key: CASSANDRA-11963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11963 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Holmberg >Priority: Minor > Fix For: 2.1.x, 2.2.x > > > Paged queries are artificially limited to Integer.MAX_INT rows in total. This > appears to be related to PagingState.remaining, which decrements > monotonically as pages are consumed. > I don't think this is intentional behavior, and haven't found any mention of > it in the docs. > Issue observed in latest 2.1 and 2.2 releases. Does not occur in 3.x -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11963) Paged queries limited to Integer.MAX_VALUE total rows
[ https://issues.apache.org/jira/browse/CASSANDRA-11963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318823#comment-15318823 ] Adam Holmberg edited comment on CASSANDRA-11963 at 6/7/16 4:34 PM: --- This is not a huge concern to me (scans like this can be broken up using token()), but just for the sake of discussion, is there any reason PagingState.remaining could just be reset for each page of the query? That seems to be the behavior in 3.0. It wouldn't require any change in format, and there was never any client contract on the semantics of those parts. Most clients of which I'm aware treat them as opaque blobs. Also, I don't think that changes the PagingState semantics from a server cursor perspective -- it just removes the limitation. was (Author: aholmber): This is not a huge concern to me (scans like this can be broken up using token()), but just for the sake of discussion, is there any reason PagingState.remaining could just be reset for each paged of the query? That seems to be the behavior in 3.0. It wouldn't require any change in format, and there was never any client contract on the semantics of those parts. Most clients of which I'm aware treat them as opaque blobs. Also, I don't think that changes the PagingState semantics from a server cursor perspective -- it just removes the limitation. > Paged queries limited to Integer.MAX_VALUE total rows > - > > Key: CASSANDRA-11963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11963 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Adam Holmberg >Priority: Minor > Fix For: 2.1.x, 2.2.x > > > Paged queries are artificially limited to Integer.MAX_INT rows in total. This > appears to be related to PagingState.remaining, which decrements > monotonically as pages are consumed. > I don't think this is intentional behavior, and haven't found any mention of > it in the docs. > Issue observed in latest 2.1 and 2.2 releases. Does not occur in 3.x -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11965) Duplicated effort in repair streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-11965.
--
Resolution: Duplicate
> Duplicated effort in repair streaming
> -
>
> Key: CASSANDRA-11965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11965
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Wei Deng
>
> [~jbellis] mentioned this as a potential improvement in his 2013 committer
> meeting notes
> (http://grokbase.com/t/cassandra/dev/132s6sh415/notes-from-committers-meeting-streaming-and-repair):
> "making the repair coordinator smarter to know when to avoid duplicate
> streaming. E.g., if replicas A and B have row X, but C does not, currently
> both A and B will stream to C."
> I tested in C* 3.0.6 and looks like this is still happening. Basically on a
> 3-node cluster I inserted into a trivial table under a keyspace with RF=3 and
> forced two flushes on all nodes so that I have two SSTables on each node,
> then I shutdown the 1st node and removed one SSTable from its data directory
> and restarted the node. I connected cqlsh to this node and verified that with
> CL.ONE the data is indeed missing; I now moved onto the 2nd node running a
> "nodetool repair ", here are what I observed from
> system.log on the 2nd node (as repair coordinator):
> {noformat}
> INFO [Thread-47] 2016-06-06 23:19:54,173 RepairRunnable.java:125 - Starting
> repair command #1, repairing keyspace weitest with repair options
> (parallelism: parallel, primary range: false, incremental: true, job threads:
> 1, ColumnFamilies: [songs], dataCenters: [], hosts: [], # of ranges: 3)
> INFO [Thread-47] 2016-06-06 23:19:54,253 RepairSession.java:237 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] new session: will sync /172.31.44.75,
> /172.31.40.215, /172.31.36.148 on range
> [(3074457345618258602,-9223372036854775808],
> (-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] for weitest.[songs]
> INFO [Repair#1:1] 2016-06-06 23:19:54,268 RepairJob.java:172 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Requesting merkle trees for songs (to
> [/172.31.40.215, /172.31.36.148, /172.31.44.75])
> INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,335 RepairSession.java:181 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
> from /172.31.40.215
> INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,427 RepairSession.java:181 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
> from /172.31.44.75
> INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,460 RepairSession.java:181 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
> from /172.31.36.148
> INFO [RepairJobTask:1] 2016-06-06 23:19:54,466 SyncTask.java:73 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
> /172.31.36.148 have 3 range(s) out of sync for songs
> INFO [RepairJobTask:1] 2016-06-06 23:19:54,467 RemoteSyncTask.java:54 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Forwarding streaming repair of
> 3 ranges to /172.31.40.215 (to be streamed with /172.31.36.148)
> INFO [RepairJobTask:1] 2016-06-06 23:19:54,472 SyncTask.java:66 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.36.148 and
> /172.31.44.75 are consistent for songs
> INFO [RepairJobTask:3] 2016-06-06 23:19:54,474 SyncTask.java:73 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
> /172.31.44.75 have 3 range(s) out of sync for songs
> INFO [RepairJobTask:3] 2016-06-06 23:19:54,529 LocalSyncTask.java:68 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Performing streaming repair of
> 3 ranges with /172.31.40.215
> INFO [RepairJobTask:3] 2016-06-06 23:19:54,574 StreamResultFuture.java:86 -
> [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57] Executing streaming plan for
> Repair
> INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,576
> StreamSession.java:238 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
> Starting streaming to /172.31.40.215
> INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,580
> StreamCoordinator.java:213 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57,
> ID#0] Beginning stream session with /172.31.40.215
> INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:54,588
> StreamResultFuture.java:168 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 1 files(174
> bytes)
> INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,117
> StreamResultFuture.java:182 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
> Session with /172.31.40.215 is complete
> INFO [STREAM-IN-/172.31.40.215
[jira] [Commented] (CASSANDRA-11345) Assertion Errors "Memory was freed" during streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-11345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318774#comment-15318774
]
Yuki Morishita commented on CASSANDRA-11345:
[StreamTransferTaskTest is
failing.|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-11345-testall/lastCompletedBuild/testReport/org.apache.cassandra.streaming/StreamTransferTaskTest/testScheduleTimeout/]
I think this is due to [opposite check
here|https://github.com/pauloricardomg/cassandra/blob/d2784f0bab9b629aead1625d28955cc513be2e79/src/java/org/apache/cassandra/streaming/messages/OutgoingFileMessage.java#L124].
Shouldn't it be {{if (transferring)}}?
> Assertion Errors "Memory was freed" during streaming
>
>
> Key: CASSANDRA-11345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11345
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Jean-Francois Gosselin
>Assignee: Paulo Motta
>
> We encountered the following AssertionError (twice on the same node) during a
> repair :
> On node /172.16.63.41
> {noformat}
> INFO [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900
> StreamResultFuture.java:180 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e]
> Session with /10.174.216.160 is complete
>
> WARN [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900
> StreamResultFuture.java:207 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e]
> Stream failed
> ERROR [STREAM-OUT-/10.174.216.160] 2016-03-09 02:38:13,906
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e]
> Streaming error occurred
> java.lang.AssertionError: Memory was freed
>
>
> at
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:97)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
>
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:249)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
>
> at
> org.apache.cassandra.io.compress.CompressionMetadata.getTotalSizeForSections(CompressionMetadata.java:247)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.messages.FileMessageHeader.size(FileMessageHeader.java:112)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.StreamSession.fileSent(StreamSession.java:546)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
>
> at
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:50)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:41)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:331)
> ~[apache-cassandra-2.1.13.jar:2.1.13]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
>
>
> {noformat}
> On node /10.174.216.160
>
> {noformat}
> ERROR [STREAM-OUT-/172.16.63.41] 2016-03-09 02:38:14,140
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e]
> Streaming error occurred
> java.io.IOException: Connection reset by peer
>
>
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.7.0_65]
>
>
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> ~[na:1.7.0_65]
>
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.j
[jira] [Commented] (CASSANDRA-11965) Duplicated effort in repair streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318770#comment-15318770
]
Sylvain Lebresne commented on CASSANDRA-11965:
--
This is indeed still happening and we have in fact a ticket for this:
CASSANDRA-3200. As I mentioned in that ticket, I looked at it a while ago and
found out there was a lot of fighting to do with the current code to make that
work properly, and I kind of gave up (hence the "later" current resolution).
That said, it is possible and would absolutely be a improvement, and probably a
non-negligible one in many cases. That said, I think repair has quite a few
issues and I'm currently a bit curious of where we can go with CASSANDRA-8911,
and if that couldn't just be a better way to do repair in the log run
(mentioning that so that anyone that would be willing to invest lots of time
changing/optimizing current repair is aware of it).
In any case, closing this as duplicate of CASSANDRA-3200 since there has
already been some discussing in that later ticket. Feel free to re-open that
latter ticket if you want to bring attention to the issue (but, for what it's
worth, I don't personally intent to spend time on that issue in the short time
for the reasons I mention above).
> Duplicated effort in repair streaming
> -
>
> Key: CASSANDRA-11965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11965
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Wei Deng
>
> [~jbellis] mentioned this as a potential improvement in his 2013 committer
> meeting notes
> (http://grokbase.com/t/cassandra/dev/132s6sh415/notes-from-committers-meeting-streaming-and-repair):
> "making the repair coordinator smarter to know when to avoid duplicate
> streaming. E.g., if replicas A and B have row X, but C does not, currently
> both A and B will stream to C."
> I tested in C* 3.0.6 and looks like this is still happening. Basically on a
> 3-node cluster I inserted into a trivial table under a keyspace with RF=3 and
> forced two flushes on all nodes so that I have two SSTables on each node,
> then I shutdown the 1st node and removed one SSTable from its data directory
> and restarted the node. I connected cqlsh to this node and verified that with
> CL.ONE the data is indeed missing; I now moved onto the 2nd node running a
> "nodetool repair ", here are what I observed from
> system.log on the 2nd node (as repair coordinator):
> {noformat}
> INFO [Thread-47] 2016-06-06 23:19:54,173 RepairRunnable.java:125 - Starting
> repair command #1, repairing keyspace weitest with repair options
> (parallelism: parallel, primary range: false, incremental: true, job threads:
> 1, ColumnFamilies: [songs], dataCenters: [], hosts: [], # of ranges: 3)
> INFO [Thread-47] 2016-06-06 23:19:54,253 RepairSession.java:237 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] new session: will sync /172.31.44.75,
> /172.31.40.215, /172.31.36.148 on range
> [(3074457345618258602,-9223372036854775808],
> (-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] for weitest.[songs]
> INFO [Repair#1:1] 2016-06-06 23:19:54,268 RepairJob.java:172 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Requesting merkle trees for songs (to
> [/172.31.40.215, /172.31.36.148, /172.31.44.75])
> INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,335 RepairSession.java:181 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
> from /172.31.40.215
> INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,427 RepairSession.java:181 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
> from /172.31.44.75
> INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,460 RepairSession.java:181 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
> from /172.31.36.148
> INFO [RepairJobTask:1] 2016-06-06 23:19:54,466 SyncTask.java:73 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
> /172.31.36.148 have 3 range(s) out of sync for songs
> INFO [RepairJobTask:1] 2016-06-06 23:19:54,467 RemoteSyncTask.java:54 -
> [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Forwarding streaming repair of
> 3 ranges to /172.31.40.215 (to be streamed with /172.31.36.148)
> INFO [RepairJobTask:1] 2016-06-06 23:19:54,472 SyncTask.java:66 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.36.148 and
> /172.31.44.75 are consistent for songs
> INFO [RepairJobTask:3] 2016-06-06 23:19:54,474 SyncTask.java:73 - [repair
> #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
> /172.31.44.75 have 3 range(s) out of sync for songs
> INFO [RepairJobTask:3] 2016-06-06 23:19:54,529 Lo
[jira] [Commented] (CASSANDRA-11963) Paged queries limited to Integer.MAX_VALUE total rows
[
https://issues.apache.org/jira/browse/CASSANDRA-11963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318744#comment-15318744
]
Sylvain Lebresne commented on CASSANDRA-11963:
--
You are right, and I guess it's some form of oversight. {{Integer.MAX_INT}}
sounded "good enough for everyone" on first approximation (read, for any query
that is meant to be somewhat real-time), but I certainly can see how you could
blew it out if you iterate over a large chunk of your database.
Unfortunately, I'm not sure how feasible it is to fix this in 2.1/2.2: we can't
change the format of the paging state without breaking backward compatibility
and are thus stuck to 4 bytes. Fortunately, for 3.0, we have changed the paging
state format and use vints which will allow use to transparently pass a long.
Given this, and given that this is the first time someone complains about this
(as in, I don't think people are hitting this limitation all the time), I
suggest we fix this in 3.0+ and just document it as a limitation in prior
versions.
> Paged queries limited to Integer.MAX_VALUE total rows
> -
>
> Key: CASSANDRA-11963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11963
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Adam Holmberg
>Priority: Minor
> Fix For: 2.1.x, 2.2.x
>
>
> Paged queries are artificially limited to Integer.MAX_INT rows in total. This
> appears to be related to PagingState.remaining, which decrements
> monotonically as pages are consumed.
> I don't think this is intentional behavior, and haven't found any mention of
> it in the docs.
> Issue observed in latest 2.1 and 2.2 releases. Does not occur in 3.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)
[ https://issues.apache.org/jira/browse/CASSANDRA-8844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318717#comment-15318717 ] Jim Witschey commented on CASSANDRA-8844: - I've pushed another PR with a new CDC dtest: https://github.com/riptano/cassandra-dtest/pull/1023 It depends on the previous one. > Change Data Capture (CDC) > - > > Key: CASSANDRA-8844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8844 > Project: Cassandra > Issue Type: New Feature > Components: Coordination, Local Write-Read Paths >Reporter: Tupshin Harper >Assignee: Joshua McKenzie >Priority: Critical > Fix For: 3.x > > > "In databases, change data capture (CDC) is a set of software design patterns > used to determine (and track) the data that has changed so that action can be > taken using the changed data. Also, Change data capture (CDC) is an approach > to data integration that is based on the identification, capture and delivery > of the changes made to enterprise data sources." > -Wikipedia > As Cassandra is increasingly being used as the Source of Record (SoR) for > mission critical data in large enterprises, it is increasingly being called > upon to act as the central hub of traffic and data flow to other systems. In > order to try to address the general need, we (cc [~brianmhess]), propose > implementing a simple data logging mechanism to enable per-table CDC patterns. > h2. The goals: > # Use CQL as the primary ingestion mechanism, in order to leverage its > Consistency Level semantics, and in order to treat it as the single > reliable/durable SoR for the data. > # To provide a mechanism for implementing good and reliable > (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) > continuous semi-realtime feeds of mutations going into a Cassandra cluster. > # To eliminate the developmental and operational burden of users so that they > don't have to do dual writes to other systems. > # For users that are currently doing batch export from a Cassandra system, > give them the opportunity to make that realtime with a minimum of coding. > h2. The mechanism: > We propose a durable logging mechanism that functions similar to a commitlog, > with the following nuances: > - Takes place on every node, not just the coordinator, so RF number of copies > are logged. > - Separate log per table. > - Per-table configuration. Only tables that are specified as CDC_LOG would do > any logging. > - Per DC. We are trying to keep the complexity to a minimum to make this an > easy enhancement, but most likely use cases would prefer to only implement > CDC logging in one (or a subset) of the DCs that are being replicated to > - In the critical path of ConsistencyLevel acknowledgment. Just as with the > commitlog, failure to write to the CDC log should fail that node's write. If > that means the requested consistency level was not met, then clients *should* > experience UnavailableExceptions. > - Be written in a Row-centric manner such that it is easy for consumers to > reconstitute rows atomically. > - Written in a simple format designed to be consumed *directly* by daemons > written in non JVM languages > h2. Nice-to-haves > I strongly suspect that the following features will be asked for, but I also > believe that they can be deferred for a subsequent release, and to guage > actual interest. > - Multiple logs per table. This would make it easy to have multiple > "subscribers" to a single table's changes. A workaround would be to create a > forking daemon listener, but that's not a great answer. > - Log filtering. Being able to apply filters, including UDF-based filters > would make Casandra a much more versatile feeder into other systems, and > again, reduce complexity that would otherwise need to be built into the > daemons. > h2. Format and Consumption > - Cassandra would only write to the CDC log, and never delete from it. > - Cleaning up consumed logfiles would be the client daemon's responibility > - Logfile size should probably be configurable. > - Logfiles should be named with a predictable naming schema, making it > triivial to process them in order. > - Daemons should be able to checkpoint their work, and resume from where they > left off. This means they would have to leave some file artifact in the CDC > log's directory. > - A sophisticated daemon should be able to be written that could > -- Catch up, in written-order, even when it is multiple logfiles behind in > processing > -- Be able to continuously "tail" the most recent logfile and get > low-latency(ms?) access to the data as it is written. > h2. Alternate approach > In order to make consuming a change log easy and efficient to do with low > latency, the following could supplement the approac
[jira] [Commented] (CASSANDRA-11913) BufferUnderFlowException in CompressorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318714#comment-15318714
]
Branimir Lambov commented on CASSANDRA-11913:
-
Thank for the patch. I would not change the array size to still catch the bug
of compressor using the size of the array instead of passed length. Fixing just
the {{arrayCopy}} should be enough to sort the problem.
> BufferUnderFlowException in CompressorTest
> --
>
> Key: CASSANDRA-11913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11913
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
> Environment: Non-x86 environments
>Reporter: Rei Odaira
>Assignee: Rei Odaira
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 11913-2.2.txt
>
>
> org.apache.cassandra.io.compress.CompressorTest causes
> java.nio.BufferUnderflowException on environments where FastByteOperations
> uses PureJavaOperations. The root cause is that
> CompressorTest.testArrayUncompress() copies data from a ByteBuffer to a byte
> array beyond the limit of the ByteBuffer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11954) Generalize SASI indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318705#comment-15318705
]
Sylvain Lebresne commented on CASSANDRA-11954:
--
You're only talking about refactoring the SASI code slightly so it's easier for
other implementations to reuse some of the parts right? If so, assuming said
refactoring make sense and don't have particular drawbacks, I don't have any
problem with that.
> Generalize SASI indexes
> ---
>
> Key: CASSANDRA-11954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths, sasi
>Reporter: Andrés de la Peña
>Priority: Minor
> Labels: 2i, sasi, secondary_index
> Fix For: 3.x
>
>
> It would be great to independize SASI indexes from their underlying index
> structure and query syntax. This way it would be easy to create new custom
> SSTable attached index implementations for specific use cases.
> The API could consist on two of interfaces, one for on-memory indexes and
> other for on-disk indexes, implemented by users and invoked by Cassandra when
> there are row writes, SSTable flushes, compactions, etc.
> As an example, the API could be used to build an efficient SASI geospatial
> index based on R-trees:
> {code}
> CREATE TABLE locations (
> id text,
> date timeuuid,
> location tuple,
> PRIMARY KEY (id, date)
> );
> CREATE CUSTOM INDEX idx ON locations () USING '...' WITH OPTIONS = {...};
> INSERT INTO locations (id, date, location) VALUES ('alice', now(), (-0.18676,
> 51.66870));
> SELECT * FROM locations WHERE expr(idx, 'POLYGON((-0.25 51.76, -0.25 51.54,
> -0.027 51.65, -0.25 51.76))');
> {code}
> Also, custom SASI indexes predicates could be combined with regular SASI
> indexes predicates in the same query, which would be very nice.
> What do you think? Does it make any sense?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10961) Not enough bytes error when add nodes to cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318700#comment-15318700
]
Sylvain Lebresne commented on CASSANDRA-10961:
--
What do you mean by "similar" exactly? Did you have a stack trace server side?
In which case, can you paste it here so we can decide if we want to open a
follow-up (as I suspect it might not be streaming related)?
> Not enough bytes error when add nodes to cluster
>
>
> Key: CASSANDRA-10961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10961
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: xiaost
>Assignee: Paulo Motta
> Fix For: 2.1.13, 2.2.5, 3.0.3, 3.3
>
> Attachments: apache-cassandra-2.2.4-SNAPSHOT.jar, debug.1.log,
> debug.logs.zip, netstats.1.log
>
>
> we got the same problem all the time when we add nodes to cluster.
> netstats:
> on HostA
> {noformat}
> /la-38395-big-Data.db 14792091851/14792091851 bytes(100%) sent to idx:0/HostB
> {noformat}
> on HostB
> {noformat}
> tmp-la-4-big-Data.db 2667087450/14792091851 bytes(18%) received from
> idx:0/HostA
> {noformat}
> After a while, Error on HostB
> {noformat}
> WARN [STREAM-IN-/HostA] 2016-01-02 12:08:14,737 StreamSession.java:644 -
> [Stream #b91a4e90-b105-11e5-bd57-dd0cc3b4634c] Retrying for following error
> java.lang.IllegalArgumentException: Not enough bytes
> at
> org.apache.cassandra.db.composites.AbstractCType.checkRemaining(AbstractCType.java:362)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.composites.AbstractCompoundCellNameType.fromByteBuffer(AbstractCompoundCellNameType.java:98)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:365)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.appendFromStream(BigTableWriter.java:243)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.StreamReader.writeRow(StreamReader.java:173)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:95)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:49)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> [apache-cassandra-2.2.4.jar:2.2.4]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66-internal]
> ERROR [Thread-28] 2016-01-02 12:08:14,737 CassandraDaemon.java:185 -
> Exception in thread Thread[Thread-28,5,main]
> java.lang.RuntimeException: java.lang.InterruptedException
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.2.4.jar:2.2.4]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_66-internal]
> Caused by: java.lang.InterruptedException: null
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220)
> ~[na:1.8.0_66-internal]
> at
> java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)
> ~[na:1.8.0_66-internal]
> at
> java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:350)
> ~[na:1.8.0_66-internal]
> at
> org.apache.cassandra.streaming.compre
[jira] [Updated] (CASSANDRA-11965) Duplicated effort in repair streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Deng updated CASSANDRA-11965:
-
Description:
[~jbellis] mentioned this as a potential improvement in his 2013 committer
meeting notes
(http://grokbase.com/t/cassandra/dev/132s6sh415/notes-from-committers-meeting-streaming-and-repair):
"making the repair coordinator smarter to know when to avoid duplicate
streaming. E.g., if replicas A and B have row X, but C does not, currently both
A and B will stream to C."
I tested in C* 3.0.6 and looks like this is still happening. Basically on a
3-node cluster I inserted into a trivial table under a keyspace with RF=3 and
forced two flushes on all nodes so that I have two SSTables on each node, then
I shutdown the 1st node and removed one SSTable from its data directory and
restarted the node. I connected cqlsh to this node and verified that with
CL.ONE the data is indeed missing; I now moved onto the 2nd node running a
"nodetool repair ", here are what I observed from system.log
on the 2nd node (as repair coordinator):
{noformat}
INFO [Thread-47] 2016-06-06 23:19:54,173 RepairRunnable.java:125 - Starting
repair command #1, repairing keyspace weitest with repair options (parallelism:
parallel, primary range: false, incremental: true, job threads: 1,
ColumnFamilies: [songs], dataCenters: [], hosts: [], # of ranges: 3)
INFO [Thread-47] 2016-06-06 23:19:54,253 RepairSession.java:237 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] new session: will sync /172.31.44.75,
/172.31.40.215, /172.31.36.148 on range
[(3074457345618258602,-9223372036854775808],
(-9223372036854775808,-3074457345618258603],
(-3074457345618258603,3074457345618258602]] for weitest.[songs]
INFO [Repair#1:1] 2016-06-06 23:19:54,268 RepairJob.java:172 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Requesting merkle trees for songs (to
[/172.31.40.215, /172.31.36.148, /172.31.44.75])
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,335 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.40.215
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,427 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.44.75
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,460 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.36.148
INFO [RepairJobTask:1] 2016-06-06 23:19:54,466 SyncTask.java:73 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
/172.31.36.148 have 3 range(s) out of sync for songs
INFO [RepairJobTask:1] 2016-06-06 23:19:54,467 RemoteSyncTask.java:54 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Forwarding streaming repair of 3
ranges to /172.31.40.215 (to be streamed with /172.31.36.148)
INFO [RepairJobTask:1] 2016-06-06 23:19:54,472 SyncTask.java:66 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.36.148 and
/172.31.44.75 are consistent for songs
INFO [RepairJobTask:3] 2016-06-06 23:19:54,474 SyncTask.java:73 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
/172.31.44.75 have 3 range(s) out of sync for songs
INFO [RepairJobTask:3] 2016-06-06 23:19:54,529 LocalSyncTask.java:68 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Performing streaming repair of 3
ranges with /172.31.40.215
INFO [RepairJobTask:3] 2016-06-06 23:19:54,574 StreamResultFuture.java:86 -
[Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57] Executing streaming plan for
Repair
INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,576
StreamSession.java:238 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
Starting streaming to /172.31.40.215
INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,580
StreamCoordinator.java:213 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57,
ID#0] Beginning stream session with /172.31.40.215
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:54,588
StreamResultFuture.java:168 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57
ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 1 files(174 bytes)
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,117
StreamResultFuture.java:182 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
Session with /172.31.40.215 is complete
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,120
StreamResultFuture.java:214 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
All sessions completed
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,123
LocalSyncTask.java:114 - [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Sync
complete using session 2d177cc0-2c3d-11e6-94d2-b35b6c93de57 between
/172.31.40.215 and /172.31.44.75 on songs
INFO [RepairJobTask:3] 2016-06-06 23:19:55,123 RepairJob.java:143 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] songs is fully s
[jira] [Updated] (CASSANDRA-11965) Duplicated effort in repair streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Deng updated CASSANDRA-11965:
-
Description:
[~jbellis] mentioned this as a potential improvement in his 2013 committer
meeting notes
(http://grokbase.com/t/cassandra/dev/132s6sh415/notes-from-committers-meeting-streaming-and-repair):
"making the repair coordinator smarter to know when to avoid duplicate
streaming. E.g., if replicas A and B have row X, but C does not, currently both
A and B will stream to C."
I tested in C* 3.0.6 and looks like this is still happening. Basically on a
3-node cluster I inserted into a trivial table under a keyspace with RF=3 and
forced two flushes on all nodes so that I have two SSTables on each node, then
I shutdown the 1st node and removed one SSTable from its data directory and
restarted the node. I connected cqlsh to this node and verified that with
CL.ONE the data is indeed missing; I now moved onto the 2nd node running a
"nodetool repair ", here are what I observed from system.log
on the 2nd node (as repair coordinator):
{noformat}
INFO [Thread-47] 2016-06-06 23:19:54,173 RepairRunnable.java:125 - Starting
repair command #1, repairing keyspace weitest with repair options (parallelism:
parallel, primary range: false, incremental: true, job threads: 1,
ColumnFamilies: [songs], dataCenters: [], hosts: [], # of ranges: 3)
INFO [Thread-47] 2016-06-06 23:19:54,253 RepairSession.java:237 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] new session: will sync /172.31.44.75,
/172.31.40.215, /172.31.36.148 on range
[(3074457345618258602,-9223372036854775808],
(-9223372036854775808,-3074457345618258603],
(-3074457345618258603,3074457345618258602]] for weitest.[songs]
INFO [Repair#1:1] 2016-06-06 23:19:54,268 RepairJob.java:172 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Requesting merkle trees for songs (to
[/172.31.40.215, /172.31.36.148, /172.31.44.75])
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,335 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.40.215
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,427 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.44.75
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,460 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.36.148
INFO [RepairJobTask:1] 2016-06-06 23:19:54,466 SyncTask.java:73 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
/172.31.36.148 have 3 range(s) out of sync for songs
INFO [RepairJobTask:1] 2016-06-06 23:19:54,467 RemoteSyncTask.java:54 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Forwarding streaming repair of 3
ranges to /172.31.40.215 (to be streamed with /172.31.36.148)
INFO [RepairJobTask:1] 2016-06-06 23:19:54,472 SyncTask.java:66 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.36.148 and
/172.31.44.75 are consistent for songs
INFO [RepairJobTask:3] 2016-06-06 23:19:54,474 SyncTask.java:73 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
/172.31.44.75 have 3 range(s) out of sync for songs
INFO [RepairJobTask:3] 2016-06-06 23:19:54,529 LocalSyncTask.java:68 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Performing streaming repair of 3
ranges with /172.31.40.215
INFO [RepairJobTask:3] 2016-06-06 23:19:54,574 StreamResultFuture.java:86 -
[Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57] Executing streaming plan for
Repair
INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,576
StreamSession.java:238 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
Starting streaming to /172.31.40.215
INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,580
StreamCoordinator.java:213 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57,
ID#0] Beginning stream session with /172.31.40.215
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:54,588
StreamResultFuture.java:168 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57
ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 1 files(174 bytes)
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,117
StreamResultFuture.java:182 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
Session with /172.31.40.215 is complete
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,120
StreamResultFuture.java:214 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
All sessions completed
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,123
LocalSyncTask.java:114 - [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Sync
complete using session 2d177cc0-2c3d-11e6-94d2-b35b6c93de57 between
/172.31.40.215 and /172.31.44.75 on songs
INFO [RepairJobTask:3] 2016-06-06 23:19:55,123 RepairJob.java:143 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] songs is fully s
[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)
[
https://issues.apache.org/jira/browse/CASSANDRA-8844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318687#comment-15318687
]
Branimir Lambov commented on CASSANDRA-8844:
Thanks for the update.
I am worried about the {{cdcSizeCalculationExecutor}} task list size. On one
hand we can add tasks at a high rate if there are a lot of attempted cdc
writes, on the other size recalculation and
[{{processNewSegment}}|https://github.com/apache/cassandra/commit/5ff4adb0e01ea0668b513211298dacc829887e97#diff-878dc31866184d5ef750ccd9befc8382R193]
both call each other, which in a space-exhausted situation this will mean a
new task added for each one removed by {{cdcSizeCalculationExecutor}} and its
list never shrinking.
The easiest way I can think of to sort this out is to use an executor with a
bounded queue of small size (I don't think we want any more than 1 or 2
trailing re-runs anyway) with
[{{DiscardPolicy}}|https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html]
as the rejected execution policy.
Nits:
I think it's safer to synchronize on the segment in
{{processNewSegment/processDiscardedSegment}} and make {{setCDCState}} also
synchronize if {{newState != cdcState}}.
The [{{setCDCstate}}
comment|https://github.com/apache/cassandra/commit/5ff4adb0e01ea0668b513211298dacc829887e97#diff-7720d4b5123a354876e0b3139222f34eR616]
is not what the code does.
{quote}
bq. CommitLogSegmentManagerCDC.discard should swap the order of
removeUnflushedSize and addFlushedSize, otherwise atCapacity may flip
in-between when space isn't actually available.
Should be addressed w/new code.
{quote}
We still have the same problem (as {{totalCDCSizeOnDisk}} does not sync). Since
we use atomics that enforce happens-before, swapping the order in
[{{processDiscardedSegment}}|https://github.com/apache/cassandra/commit/5ff4adb0e01ea0668b513211298dacc829887e97#diff-878dc31866184d5ef750ccd9befc8382R202]
will be sufficient to fix it.
> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
> Issue Type: New Feature
> Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 3.x
>
>
> "In databases, change data capture (CDC) is a set of software design patterns
> used to determine (and track) the data that has changed so that action can be
> taken using the changed data. Also, Change data capture (CDC) is an approach
> to data integration that is based on the identification, capture and delivery
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for
> mission critical data in large enterprises, it is increasingly being called
> upon to act as the central hub of traffic and data flow to other systems. In
> order to try to address the general need, we (cc [~brianmhess]), propose
> implementing a simple data logging mechanism to enable per-table CDC patterns.
> h2. The goals:
> # Use CQL as the primary ingestion mechanism, in order to leverage its
> Consistency Level semantics, and in order to treat it as the single
> reliable/durable SoR for the data.
> # To provide a mechanism for implementing good and reliable
> (deliver-at-least-once with possible mechanisms for deliver-exactly-once )
> continuous semi-realtime feeds of mutations going into a Cassandra cluster.
> # To eliminate the developmental and operational burden of users so that they
> don't have to do dual writes to other systems.
> # For users that are currently doing batch export from a Cassandra system,
> give them the opportunity to make that realtime with a minimum of coding.
> h2. The mechanism:
> We propose a durable logging mechanism that functions similar to a commitlog,
> with the following nuances:
> - Takes place on every node, not just the coordinator, so RF number of copies
> are logged.
> - Separate log per table.
> - Per-table configuration. Only tables that are specified as CDC_LOG would do
> any logging.
> - Per DC. We are trying to keep the complexity to a minimum to make this an
> easy enhancement, but most likely use cases would prefer to only implement
> CDC logging in one (or a subset) of the DCs that are being replicated to
> - In the critical path of ConsistencyLevel acknowledgment. Just as with the
> commitlog, failure to write to the CDC log should fail that node's write. If
> that means the requested consistency level was not met, then clients *should*
> experience UnavailableExceptions.
> - Be written in a Row-centric manner such that it is easy for consumers to
> reconstitute rows atomically.
> - Written in a simple forma
[jira] [Created] (CASSANDRA-11965) Duplicated effort in repair streaming
Wei Deng created CASSANDRA-11965:
Summary: Duplicated effort in repair streaming
Key: CASSANDRA-11965
URL: https://issues.apache.org/jira/browse/CASSANDRA-11965
Project: Cassandra
Issue Type: Improvement
Components: Streaming and Messaging
Reporter: Wei Deng
[~jbellis] mentioned this as a potential improvement in his 2013 committer
meeting notes
(http://grokbase.com/t/cassandra/dev/132s6sh415/notes-from-committers-meeting-streaming-and-repair):
"making the repair coordinator smarter to know when to avoid duplicate
streaming. E.g., if replicas A and B have row X, but C does not, currently both
A and B will stream to C."
I tested in C* 3.0.6 and looks like this is still happening. Basically on a
3-node cluster I inserted into a trivial table under a keyspace with RF=3 and
forced two flushes on all nodes so that I have two SSTables on each node, then
I shutdown the 1st node and removed one SSTable from its data directory and
restarted the node. I connected cqlsh to this node and verified that with
CL.ONE the data is indeed missing; I now moved onto the 2nd node running a
"nodetool repair ", here are what I observed from system.log
on the 2nd node (as repair coordinator):
{noformat}
INFO [Thread-47] 2016-06-06 23:19:54,173 RepairRunnable.java:125 - Starting
repair command #1, repairing keyspace weitest with repair options (parallelism:
parallel, primary range: false, incremental: true, job threads: 1,
ColumnFamilies: [songs], dataCenters: [], hosts: [], # of ranges: 3)
INFO [Thread-47] 2016-06-06 23:19:54,253 RepairSession.java:237 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] new session: will sync /172.31.44.75,
/172.31.40.215, /172.31.36.148 on range
[(3074457345618258602,-9223372036854775808],
(-9223372036854775808,-3074457345618258603],
(-3074457345618258603,3074457345618258602]] for weitest.[songs]
INFO [Repair#1:1] 2016-06-06 23:19:54,268 RepairJob.java:172 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Requesting merkle trees for songs (to
[/172.31.40.215, /172.31.36.148, /172.31.44.75])
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,335 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.40.215
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,427 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.44.75
INFO [AntiEntropyStage:1] 2016-06-06 23:19:54,460 RepairSession.java:181 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Received merkle tree for songs
from /172.31.36.148
INFO [RepairJobTask:1] 2016-06-06 23:19:54,466 SyncTask.java:73 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
/172.31.36.148 have 3 range(s) out of sync for songs
INFO [RepairJobTask:1] 2016-06-06 23:19:54,467 RemoteSyncTask.java:54 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Forwarding streaming repair of 3
ranges to /172.31.40.215 (to be streamed with /172.31.36.148)
INFO [RepairJobTask:1] 2016-06-06 23:19:54,472 SyncTask.java:66 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.36.148 and
/172.31.44.75 are consistent for songs
INFO [RepairJobTask:3] 2016-06-06 23:19:54,474 SyncTask.java:73 - [repair
#2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Endpoints /172.31.40.215 and
/172.31.44.75 have 3 range(s) out of sync for songs
INFO [RepairJobTask:3] 2016-06-06 23:19:54,529 LocalSyncTask.java:68 -
[repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Performing streaming repair of 3
ranges with /172.31.40.215
INFO [RepairJobTask:3] 2016-06-06 23:19:54,574 StreamResultFuture.java:86 -
[Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57] Executing streaming plan for
Repair
INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,576
StreamSession.java:238 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
Starting streaming to /172.31.40.215
INFO [StreamConnectionEstablisher:1] 2016-06-06 23:19:54,580
StreamCoordinator.java:213 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57,
ID#0] Beginning stream session with /172.31.40.215
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:54,588
StreamResultFuture.java:168 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57
ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 1 files(174 bytes)
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,117
StreamResultFuture.java:182 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
Session with /172.31.40.215 is complete
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,120
StreamResultFuture.java:214 - [Stream #2d423640-2c3d-11e6-94d2-b35b6c93de57]
All sessions completed
INFO [STREAM-IN-/172.31.40.215] 2016-06-06 23:19:55,123
LocalSyncTask.java:114 - [repair #2d177cc0-2c3d-11e6-94d2-b35b6c93de57] Sync
complete using session 2d177cc0-2c3d-11e6-94d2-b35b6c93de57 between
/172
[jira] [Resolved] (CASSANDRA-11964) 404 link on http://docs.datastax.com/
[ https://issues.apache.org/jira/browse/CASSANDRA-11964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan resolved CASSANDRA-11964. - Resolution: Invalid > 404 link on http://docs.datastax.com/ > - > > Key: CASSANDRA-11964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11964 > Project: Cassandra > Issue Type: Bug >Reporter: Iouri Goussev >Priority: Trivial > > On > http://docs.datastax.com/en/cassandra/2.0/cassandra/initialize/initializeSingleDS.html > ...see the Cassandra & DataStax Enterprise Essentials.. > links to a non-existent page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11964) 404 link on http://docs.datastax.com/
[ https://issues.apache.org/jira/browse/CASSANDRA-11964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318670#comment-15318670 ] Jeremiah Jordan commented on CASSANDRA-11964: - Those docs are from DataStax and not the Apache Cassandra project. Their docs team has a twitter account if you would like to let them know: https://twitter.com/DataStaxDocs > 404 link on http://docs.datastax.com/ > - > > Key: CASSANDRA-11964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11964 > Project: Cassandra > Issue Type: Bug >Reporter: Iouri Goussev >Priority: Trivial > > On > http://docs.datastax.com/en/cassandra/2.0/cassandra/initialize/initializeSingleDS.html > ...see the Cassandra & DataStax Enterprise Essentials.. > links to a non-existent page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11964) 404 link on http://docs.datastax.com/
[ https://issues.apache.org/jira/browse/CASSANDRA-11964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-11964: Component/s: (was: Documentation and Website) > 404 link on http://docs.datastax.com/ > - > > Key: CASSANDRA-11964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11964 > Project: Cassandra > Issue Type: Bug >Reporter: Iouri Goussev >Priority: Trivial > > On > http://docs.datastax.com/en/cassandra/2.0/cassandra/initialize/initializeSingleDS.html > ...see the Cassandra & DataStax Enterprise Essentials.. > links to a non-existent page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11854) Remove finished streaming connections from MessagingService
[
https://issues.apache.org/jira/browse/CASSANDRA-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318661#comment-15318661
]
Yuki Morishita commented on CASSANDRA-11854:
Thanks for the patch.
* You actually registerring 2 callbacks (for incoming and outgoing) to the same
{{StreamResultFuture}} instance. It is harmless, but isn't it better to pass
callback to {{initReceivingSide}}?
* I prefer putting {{IncomingStreamingConnection.this}} instead of {{this}} in
callback for clarity.
> Remove finished streaming connections from MessagingService
> ---
>
> Key: CASSANDRA-11854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11854
> Project: Cassandra
> Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Attachments: oom.png
>
>
> When a new {{IncomingStreamingConnection}} is created, [we register it in the
> connections
> map|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessagingService.java#L1109]
> of {{MessagingService}}, but we [only remove it if there is an
> exception|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/IncomingStreamingConnection.java#L83]
> while attaching the socket to the stream session.
> On nodes with SSL and large number of vnodes, after many repair sessions
> these old connections can accumulate and cause OOM (heap dump attached).
> The connection should be removed from the connections map after if it's
> finished in order to be garbage collected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11854) Remove finished streaming connections from MessagingService
[
https://issues.apache.org/jira/browse/CASSANDRA-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318661#comment-15318661
]
Yuki Morishita edited comment on CASSANDRA-11854 at 6/7/16 3:19 PM:
Thanks for the patch.
* You are actually registerring 2 callbacks (for incoming and outgoing) to the
same {{StreamResultFuture}} instance. It is harmless, but isn't it better to
pass callback to {{initReceivingSide}}?
* I prefer putting {{IncomingStreamingConnection.this}} instead of {{this}} in
callback for clarity.
was (Author: yukim):
Thanks for the patch.
* You actually registerring 2 callbacks (for incoming and outgoing) to the same
{{StreamResultFuture}} instance. It is harmless, but isn't it better to pass
callback to {{initReceivingSide}}?
* I prefer putting {{IncomingStreamingConnection.this}} instead of {{this}} in
callback for clarity.
> Remove finished streaming connections from MessagingService
> ---
>
> Key: CASSANDRA-11854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11854
> Project: Cassandra
> Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
> Attachments: oom.png
>
>
> When a new {{IncomingStreamingConnection}} is created, [we register it in the
> connections
> map|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/MessagingService.java#L1109]
> of {{MessagingService}}, but we [only remove it if there is an
> exception|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/IncomingStreamingConnection.java#L83]
> while attaching the socket to the stream session.
> On nodes with SSL and large number of vnodes, after many repair sessions
> these old connections can accumulate and cause OOM (heap dump attached).
> The connection should be removed from the connections map after if it's
> finished in order to be garbage collected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11964) 404 link on http://docs.datastax.com/
Iouri Goussev created CASSANDRA-11964: - Summary: 404 link on http://docs.datastax.com/ Key: CASSANDRA-11964 URL: https://issues.apache.org/jira/browse/CASSANDRA-11964 Project: Cassandra Issue Type: Bug Components: Documentation and Website Reporter: Iouri Goussev Priority: Trivial On http://docs.datastax.com/en/cassandra/2.0/cassandra/initialize/initializeSingleDS.html ...see the Cassandra & DataStax Enterprise Essentials.. links to a non-existent page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318602#comment-15318602
]
Alex Petrov commented on CASSANDRA-10786:
-
bq. Unfortunately, server-side we invalidate all related prepared statements
whenever a schema change occurs, so there will still be some amount of full
repreparation until the v5 protocol is the minimum supported protocol version
and we can change this server-side behavior.
I've made a prototype that helps to avoid re-prepares on schema altering by
trying re-preparing statements server side instead of invalidating them, which
works quite well. Having that said, we can certainly just invalidate and wait
until the first client hits. But we'd still benefit from that on all other
clients.
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7826) support non-frozen, nested collections
[ https://issues.apache.org/jira/browse/CASSANDRA-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318599#comment-15318599 ] Sylvain Lebresne commented on CASSANDRA-7826: - This is kind of "blocked" on CASSANDRA-7396, for which I have an almost ready updated patch for, but have been finishing CASSANDRA-10783. Took me longer than expected so the lateness on progress is my fault. > support non-frozen, nested collections > -- > > Key: CASSANDRA-7826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7826 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Alex Petrov > Labels: ponies > Fix For: 3.x > > > The inability to nest collections is one of the bigger data modelling > limitations we have right now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7826) support non-frozen, nested collections
[ https://issues.apache.org/jira/browse/CASSANDRA-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318514#comment-15318514 ] Jonathan Ellis commented on CASSANDRA-7826: --- How is progress looking here? > support non-frozen, nested collections > -- > > Key: CASSANDRA-7826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7826 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Alex Petrov > Labels: ponies > Fix For: 3.x > > > The inability to nest collections is one of the bigger data modelling > limitations we have right now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11960) Hints are not seekable
[
https://issues.apache.org/jira/browse/CASSANDRA-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318414#comment-15318414
]
Stefan Podkowinski commented on CASSANDRA-11960:
This looks like this was caused by CASSANDRA-5863, where the
{{RandomAccessReader}} based input has been replaced with
{{RebufferingInputStream}}.
The way I understand how hint dispatching is currently implemented is that we
deliver hints from a file by sending individual {{HintsReader.Page}} s until
finished. In cases of any error while transmitting a page,
{{HintsStore.markDispatchOffset}} will be used to remember from where to resume
delivering hints by using a long offset. Since the byte offset based seek isn't
supported anymore due to mentioned changes, the exception is thrown.
> Hints are not seekable
> --
>
> Key: CASSANDRA-11960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11960
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>
> Got the following error message on trunk. No idea how to reproduce. But the
> only thing the (not overridden) seek method does is throwing this exception.
> {code}
> ERROR [HintsDispatcher:2] 2016-06-05 18:51:09,397 CassandraDaemon.java:222 -
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.UnsupportedOperationException: Hints are not seekable.
> at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:79)
> ~[main/:na]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:257)
> ~[main/:na]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
> ~[main/:na]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
> ~[main/:na]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_91]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
