[jira] [Updated] (CASSANDRA-14527) Real time Bad query logging framework
[ https://issues.apache.org/jira/browse/CASSANDRA-14527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaydeepkumar Chovatia updated CASSANDRA-14527: -- Description: If Cassandra is not used in right way then it can create adverse effect to the application. There are lots of bad queries when using Cassandra, but major problem is end user don’t know where and what exactly is the problem. Most of the times end user is ready to take actions on bad queries provided Cassandra gives all detailed which could have potential impact on cluster performance. There has been already lots of work done as part of CASSANDRA-12403, proposal as part of this JIRA is let’s have some common way of detecting and logging different problems in Cassandra cluster which could have potential impact on Cassandra cluster performance. Please visit this document which has details like what is currently available, motivation behind developing this common framework, architecture, samples, etc. [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] Here is the patch with this feature: ||trunk|| |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! |https://circleci.com/gh/jaydeepkumar1984/cassandra/82]| |[patch |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| Please review this doc and the patch, and provide your opinion and feedback about this effort. Thank you! was: If Cassandra is not used in right way then it can create adverse effect to the application. There are lots of bad queries when using Cassandra, but major problem is end user don’t know where and what exactly is the problem. Most of the times end user is ready to take actions on bad queries provided Cassandra gives all detailed which could have potential impact on cluster performance. There has been already lots of work done as part of CASSANDRA-12403, proposal as part of this JIRA is let’s have some common way of detecting and logging different problems in Cassandra cluster which could have potential impact on Cassandra cluster performance. Please visit this document which has details like what is currently available, motivation behind developing this common framework, architecture, samples, etc. [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] Here is the patch with this feature: ||trunk|| |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! |https://circleci.com/gh/jaydeepkumar1984/cassandra/81]| |[patch |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| Please review this doc and the patch, and provide your opinion and feedback about this effort. Thank you! > Real time Bad query logging framework > - > > Key: CASSANDRA-14527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14527 > Project: Cassandra > Issue Type: New Feature > Components: Observability >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Major > Fix For: 4.0 > > > If Cassandra is not used in right way then it can create adverse effect to > the application. There are lots of bad queries when using Cassandra, but > major problem is end user don’t know where and what exactly is the problem. > Most of the times end user is ready to take actions on bad queries provided > Cassandra gives all detailed which could have potential impact on cluster > performance. > There has been already lots of work done as part of CASSANDRA-12403, proposal > as part of this JIRA is let’s have some common way of detecting and logging > different problems in Cassandra cluster which could have potential impact on > Cassandra cluster performance. > Please visit this document which has details like what is currently > available, motivation behind developing this common framework, architecture, > samples, etc. > [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] > Here is the patch with this feature: > ||trunk|| > |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! > |https://circleci.com/gh/jaydeepkumar1984/cassandra/82]| > |[patch > |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| > Please review this doc and the patch, and provide your opinion and feedback > about this effort. > Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14527) Real time Bad query logging framework
[ https://issues.apache.org/jira/browse/CASSANDRA-14527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaydeepkumar Chovatia updated CASSANDRA-14527: -- Description: If Cassandra is not used in right way then it can create adverse effect to the application. There are lots of bad queries when using Cassandra, but major problem is end user don’t know where and what exactly is the problem. Most of the times end user is ready to take actions on bad queries provided Cassandra gives all detailed which could have potential impact on cluster performance. There has been already lots of work done as part of CASSANDRA-12403, proposal as part of this JIRA is let’s have some common way of detecting and logging different problems in Cassandra cluster which could have potential impact on Cassandra cluster performance. Please visit this document which has details like what is currently available, motivation behind developing this common framework, architecture, samples, etc. [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] Here is the patch with this feature: ||trunk|| |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! |https://circleci.com/gh/jaydeepkumar1984/cassandra/81]| |[patch |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| Please review this doc and the patch, and provide your opinion and feedback about this effort. Thank you! was: If Cassandra is not used in right way then it can create adverse effect to the application. There are lots of bad queries when using Cassandra, but major problem is end user don’t know where and what exactly is the problem. Most of the times end user is ready to take actions on bad queries provided Cassandra gives all detailed which could have potential impact on cluster performance. There has been already lots of work done as part of CASSANDRA-12403, proposal as part of this JIRA is let’s have some common way of detecting and logging different problems in Cassandra cluster which could have potential impact on Cassandra cluster performance. Please visit this document which has details like what is currently available, motivation behind developing this common framework, architecture, samples, etc. [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] Here is the patch with this feature: ||trunk|| |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! |https://circleci.com/gh/jaydeepkumar1984/cassandra/78]| |[patch |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| Please review this doc and the patch, and provide your opinion and feedback about this effort. Thank you! > Real time Bad query logging framework > - > > Key: CASSANDRA-14527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14527 > Project: Cassandra > Issue Type: New Feature > Components: Observability >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Major > Fix For: 4.0 > > > If Cassandra is not used in right way then it can create adverse effect to > the application. There are lots of bad queries when using Cassandra, but > major problem is end user don’t know where and what exactly is the problem. > Most of the times end user is ready to take actions on bad queries provided > Cassandra gives all detailed which could have potential impact on cluster > performance. > There has been already lots of work done as part of CASSANDRA-12403, proposal > as part of this JIRA is let’s have some common way of detecting and logging > different problems in Cassandra cluster which could have potential impact on > Cassandra cluster performance. > Please visit this document which has details like what is currently > available, motivation behind developing this common framework, architecture, > samples, etc. > [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] > Here is the patch with this feature: > ||trunk|| > |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! > |https://circleci.com/gh/jaydeepkumar1984/cassandra/81]| > |[patch > |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| > Please review this doc and the patch, and provide your opinion and feedback > about this effort. > Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14356) LWTs keep failing in trunk after immutable refactor
[ https://issues.apache.org/jira/browse/CASSANDRA-14356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14356: Status: Testing (was: Patch Available) > LWTs keep failing in trunk after immutable refactor > --- > > Key: CASSANDRA-14356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14356 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OpenJDK Runtime Environment (build 1.8.0_161-b14), > Cassandra 4.0 commit c22ee2bd451d030e99cfb65be839bbc735a5352f (29.3.2018 > 14:01) >Reporter: Michael Burman >Assignee: Michael Burman >Priority: Major > Fix For: 4.0 > > Attachments: CASSANDRA-14356.diff > > > In the PaxosState, the original assert check is in the form of: > assert promised.update.metadata() == accepted.update.metadata() && > accepted.update.metadata() == mostRecentCommit.update.metadata(); > However, after the change to make TableMetadata immutable this no longer > works as these instances are not necessarily the same (or never). This causes > the LWTs to fail although they're still correctly targetting the same table. > From IRC: > It's a bug alright. Though really, the assertion should be on the > metadata ids, cause TableMetadata#equals does more than what we want. > That is, replacing by .equals() is not ok. That would reject throw > on any change to a table metadata, while the spirit of the assumption was to > sanity check both update were on the same table. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14356) LWTs keep failing in trunk after immutable refactor
[ https://issues.apache.org/jira/browse/CASSANDRA-14356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514988#comment-16514988 ] mck commented on CASSANDRA-14356: - || Branch || uTest || aTest || dTest || |[trunk_14356|https://github.com/thelastpickle/cassandra/tree/mck/trunk_14356]|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Ftrunk_14356.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Ftrunk_14356]| [!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/35/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/35] | [!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/574/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/574] | > LWTs keep failing in trunk after immutable refactor > --- > > Key: CASSANDRA-14356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14356 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OpenJDK Runtime Environment (build 1.8.0_161-b14), > Cassandra 4.0 commit c22ee2bd451d030e99cfb65be839bbc735a5352f (29.3.2018 > 14:01) >Reporter: Michael Burman >Assignee: Michael Burman >Priority: Major > Fix For: 4.0 > > Attachments: CASSANDRA-14356.diff > > > In the PaxosState, the original assert check is in the form of: > assert promised.update.metadata() == accepted.update.metadata() && > accepted.update.metadata() == mostRecentCommit.update.metadata(); > However, after the change to make TableMetadata immutable this no longer > works as these instances are not necessarily the same (or never). This causes > the LWTs to fail although they're still correctly targetting the same table. > From IRC: > It's a bug alright. Though really, the assertion should be on the > metadata ids, cause TableMetadata#equals does more than what we want. > That is, replacing by .equals() is not ok. That would reject throw > on any change to a table metadata, while the spirit of the assumption was to > sanity check both update were on the same table. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14356) LWTs keep failing in trunk after immutable refactor
[ https://issues.apache.org/jira/browse/CASSANDRA-14356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514985#comment-16514985 ] mck commented on CASSANDRA-14356: - This exception is evident in Reaper's builds against Cassandra trunk, ref [travis|https://travis-ci.org/thelastpickle/cassandra-reaper/branches] > LWTs keep failing in trunk after immutable refactor > --- > > Key: CASSANDRA-14356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14356 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OpenJDK Runtime Environment (build 1.8.0_161-b14), > Cassandra 4.0 commit c22ee2bd451d030e99cfb65be839bbc735a5352f (29.3.2018 > 14:01) >Reporter: Michael Burman >Assignee: Michael Burman >Priority: Major > Fix For: 4.0 > > Attachments: CASSANDRA-14356.diff > > > In the PaxosState, the original assert check is in the form of: > assert promised.update.metadata() == accepted.update.metadata() && > accepted.update.metadata() == mostRecentCommit.update.metadata(); > However, after the change to make TableMetadata immutable this no longer > works as these instances are not necessarily the same (or never). This causes > the LWTs to fail although they're still correctly targetting the same table. > From IRC: > It's a bug alright. Though really, the assertion should be on the > metadata ids, cause TableMetadata#equals does more than what we want. > That is, replacing by .equals() is not ok. That would reject throw > on any change to a table metadata, while the spirit of the assumption was to > sanity check both update were on the same table. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14356) LWTs keep failing in trunk after immutable refactor
[ https://issues.apache.org/jira/browse/CASSANDRA-14356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14356: Reviewer: mck > LWTs keep failing in trunk after immutable refactor > --- > > Key: CASSANDRA-14356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14356 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OpenJDK Runtime Environment (build 1.8.0_161-b14), > Cassandra 4.0 commit c22ee2bd451d030e99cfb65be839bbc735a5352f (29.3.2018 > 14:01) >Reporter: Michael Burman >Assignee: Michael Burman >Priority: Major > Fix For: 4.0 > > Attachments: CASSANDRA-14356.diff > > > In the PaxosState, the original assert check is in the form of: > assert promised.update.metadata() == accepted.update.metadata() && > accepted.update.metadata() == mostRecentCommit.update.metadata(); > However, after the change to make TableMetadata immutable this no longer > works as these instances are not necessarily the same (or never). This causes > the LWTs to fail although they're still correctly targetting the same table. > From IRC: > It's a bug alright. Though really, the assertion should be on the > metadata ids, cause TableMetadata#equals does more than what we want. > That is, replacing by .equals() is not ok. That would reject throw > on any change to a table metadata, while the spirit of the assumption was to > sanity check both update were on the same table. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14356) LWTs keep failing in trunk after immutable refactor
[ https://issues.apache.org/jira/browse/CASSANDRA-14356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck reassigned CASSANDRA-14356: --- Assignee: Michael Burman > LWTs keep failing in trunk after immutable refactor > --- > > Key: CASSANDRA-14356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14356 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OpenJDK Runtime Environment (build 1.8.0_161-b14), > Cassandra 4.0 commit c22ee2bd451d030e99cfb65be839bbc735a5352f (29.3.2018 > 14:01) >Reporter: Michael Burman >Assignee: Michael Burman >Priority: Major > Fix For: 4.0 > > Attachments: CASSANDRA-14356.diff > > > In the PaxosState, the original assert check is in the form of: > assert promised.update.metadata() == accepted.update.metadata() && > accepted.update.metadata() == mostRecentCommit.update.metadata(); > However, after the change to make TableMetadata immutable this no longer > works as these instances are not necessarily the same (or never). This causes > the LWTs to fail although they're still correctly targetting the same table. > From IRC: > It's a bug alright. Though really, the assertion should be on the > metadata ids, cause TableMetadata#equals does more than what we want. > That is, replacing by .equals() is not ok. That would reject throw > on any change to a table metadata, while the spirit of the assumption was to > sanity check both update were on the same table. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9608) Support Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514917#comment-16514917
]
Jason Brown commented on CASSANDRA-9608:
created a [PR|https://github.com/apache/cassandra/pull/236] to discuss.
> Support Java 11
> ---
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 4.x
>
> Attachments: jdk_9_10.patch
>
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14527) Real time Bad query logging framework
Jaydeepkumar Chovatia created CASSANDRA-14527: - Summary: Real time Bad query logging framework Key: CASSANDRA-14527 URL: https://issues.apache.org/jira/browse/CASSANDRA-14527 Project: Cassandra Issue Type: New Feature Components: Observability Reporter: Jaydeepkumar Chovatia Assignee: Jaydeepkumar Chovatia Fix For: 4.0 If Cassandra is not used in right way then it can create adverse effect to the application. There are lots of bad queries when using Cassandra, but major problem is end user don’t know where and what exactly is the problem. Most of the times end user is ready to take actions on bad queries provided Cassandra gives all detailed which could have potential impact on cluster performance. There has been already lots of work done as part of CASSANDRA-12403, proposal as part of this JIRA is let’s have some common way of detecting and logging different problems in Cassandra cluster which could have potential impact on Cassandra cluster performance. Please visit this document which has details like what is currently available, motivation behind developing this common framework, architecture, samples, etc. [https://docs.google.com/document/d/1D0HNjC3a7gnuKnR_iDXLI5mvn1zQxtV7tloMaLYIENE/edit?usp=sharing] Here is the patch with this feature: ||trunk|| |[!https://circleci.com/gh/jaydeepkumar1984/cassandra/tree/bqr.svg?style=svg! |https://circleci.com/gh/jaydeepkumar1984/cassandra/78]| |[patch |https://github.com/apache/cassandra/compare/trunk...jaydeepkumar1984:bqr]| Please review this doc and the patch, and provide your opinion and feedback about this effort. Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14419) Resume compresed hints delivery broken
[
https://issues.apache.org/jira/browse/CASSANDRA-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-14419:
Reproduced In: 3.0.16, 3.0.15 (was: 3.0.15, 3.0.16)
Status: Patch Available (was: Open)
> Resume compresed hints delivery broken
> --
>
> Key: CASSANDRA-14419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14419
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
> Fix For: 3.0.17
>
>
> We are using Cassandra 3.0.15 and are using compressed hints, but if hint
> delivery is interrupted resuming hint delivery is failing.
> {code}
> 2018-04-04T13:27:48.948+0200 ERROR [HintsDispatcher:14]
> CassandraDaemon.java:207 Exception in thread Thread[HintsDispatcher:14,1,main]
> java.lang.IllegalArgumentException: Unable to seek to position 1789149057 in
> /var/lib/cassandra/hints/9592c860-1054-4c60-b3b8-faa9adc6d769-1522838912649-1.hints
> (118259682 bytes) in read-only mode
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:287)
> ~[apache-cassandra-clientutil-3.0.15.jar:3.0.15]
> at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:83)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:263)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:248)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:226)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:205)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_152]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_152]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> [apache-cassandra-3.0.15.jar:3.0.15]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_152]
> {code}
> I think the problem is similar to CASSANDRA-11960.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14419) Resume compresed hints delivery broken
[
https://issues.apache.org/jira/browse/CASSANDRA-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514896#comment-16514896
]
Joshua McKenzie commented on CASSANDRA-14419:
-
"Anonymous" needs to stop setting things to "Ready to Commit" once every two
months. ;)
> Resume compresed hints delivery broken
> --
>
> Key: CASSANDRA-14419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14419
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
> Fix For: 3.0.17
>
>
> We are using Cassandra 3.0.15 and are using compressed hints, but if hint
> delivery is interrupted resuming hint delivery is failing.
> {code}
> 2018-04-04T13:27:48.948+0200 ERROR [HintsDispatcher:14]
> CassandraDaemon.java:207 Exception in thread Thread[HintsDispatcher:14,1,main]
> java.lang.IllegalArgumentException: Unable to seek to position 1789149057 in
> /var/lib/cassandra/hints/9592c860-1054-4c60-b3b8-faa9adc6d769-1522838912649-1.hints
> (118259682 bytes) in read-only mode
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:287)
> ~[apache-cassandra-clientutil-3.0.15.jar:3.0.15]
> at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:83)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:263)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:248)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:226)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:205)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_152]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_152]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> [apache-cassandra-3.0.15.jar:3.0.15]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_152]
> {code}
> I think the problem is similar to CASSANDRA-11960.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14419) Resume compresed hints delivery broken
[
https://issues.apache.org/jira/browse/CASSANDRA-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-14419:
Reproduced In: 3.0.16, 3.0.15 (was: 3.0.15, 3.0.16)
Status: Open (was: Ready to Commit)
> Resume compresed hints delivery broken
> --
>
> Key: CASSANDRA-14419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14419
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
> Fix For: 3.0.17
>
>
> We are using Cassandra 3.0.15 and are using compressed hints, but if hint
> delivery is interrupted resuming hint delivery is failing.
> {code}
> 2018-04-04T13:27:48.948+0200 ERROR [HintsDispatcher:14]
> CassandraDaemon.java:207 Exception in thread Thread[HintsDispatcher:14,1,main]
> java.lang.IllegalArgumentException: Unable to seek to position 1789149057 in
> /var/lib/cassandra/hints/9592c860-1054-4c60-b3b8-faa9adc6d769-1522838912649-1.hints
> (118259682 bytes) in read-only mode
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:287)
> ~[apache-cassandra-clientutil-3.0.15.jar:3.0.15]
> at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:83)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:263)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:248)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:226)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:205)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_152]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_152]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> [apache-cassandra-3.0.15.jar:3.0.15]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_152]
> {code}
> I think the problem is similar to CASSANDRA-11960.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514851#comment-16514851
]
Venkata Harikrishna Nukala commented on CASSANDRA-14344:
[~blerer] Thanks for reviewing the patch.
I agree with the comment "approach force the deserialization of all the list
elements and of the value for each check", but as per my knowledge, this
evaluation happens as part of iterator with no additional status/context,
making it difficult to reuse deserialized values across partitions. This
approached is used by other operators too. Is there a better way?
I will add additional unit test cases.
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Major
> Attachments: 14344-trunk.txt
>
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+--+--+---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14419) Resume compresed hints delivery broken
[
https://issues.apache.org/jira/browse/CASSANDRA-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anonymous updated CASSANDRA-14419:
--
Status: Ready to Commit (was: Patch Available)
> Resume compresed hints delivery broken
> --
>
> Key: CASSANDRA-14419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14419
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
> Fix For: 3.0.17
>
>
> We are using Cassandra 3.0.15 and are using compressed hints, but if hint
> delivery is interrupted resuming hint delivery is failing.
> {code}
> 2018-04-04T13:27:48.948+0200 ERROR [HintsDispatcher:14]
> CassandraDaemon.java:207 Exception in thread Thread[HintsDispatcher:14,1,main]
> java.lang.IllegalArgumentException: Unable to seek to position 1789149057 in
> /var/lib/cassandra/hints/9592c860-1054-4c60-b3b8-faa9adc6d769-1522838912649-1.hints
> (118259682 bytes) in read-only mode
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:287)
> ~[apache-cassandra-clientutil-3.0.15.jar:3.0.15]
> at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:83)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:263)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:248)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:226)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:205)
> ~[apache-cassandra-3.0.15.jar:3.0.15]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_152]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_152]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_152]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> [apache-cassandra-3.0.15.jar:3.0.15]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_152]
> {code}
> I think the problem is similar to CASSANDRA-11960.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
