[jira] [Updated] (CASSANDRA-15025) Avoid NPE in RepairRunnable.recordFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-15025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15025:
-
Component/s: Consistency/Repair
> Avoid NPE in RepairRunnable.recordFailure
> -
>
> Key: CASSANDRA-15025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15025
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> failureMessage parameter in {{RepairRunnable.recordFailure}} can be null,
> avoid this happening and make sure we log the actual exception
--
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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: CASSANDRA-14298.txt > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- 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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Status: Patch Available (was: In Progress) Attachment CASSANDRA-14298.txt is a new patch for the head of cassandra-dtest master (currently commit e6f58cb33f7a09f273c5990d5d21c7b529ba80bf). As previously discussed on this ticket, this patch deselects 27 tests in test_cqlsh_copy.py that depend on importing the Python 2.7 cqlshlib into the Python 3 dtests, and gets the remaining tests to pass. I've gotten passing tests with this patch on AWS t2.large instances running Ubuntu and CentOS 7 with trunk, cassandra-3.11, and cassandra-3.0. The environment must have the en_US.UTF-8 locale generated, with the environment variable LC_CTYPE=en_US.UTF-8. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- 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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770270#comment-16770270 ] Patrick Bannister commented on CASSANDRA-14298: --- I'm finalizing a new patch. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- 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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- 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-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298-old.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13763) Trivial but potential security issue?
[
https://issues.apache.org/jira/browse/CASSANDRA-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770229#comment-16770229
]
C. Scott Andreas edited comment on CASSANDRA-13763 at 2/16/19 9:15 PM:
---
Thanks for reaching out, and sorry for the delay in reply to your question.
This code is part of the cassandra-stress tool, a benchmarking harness that is
typically used for load testing purposes only, and in this case would print
`null` indicating that no password was supplied by the user at the start of the
run. I don't think a substantial issue exists here.
Thanks again for the report.
was (Author: cscotta):
Thanks for reaching out, and sorry for the delay in reply to your question.
This code is part of the cassandra-stress tool, a benchmarking harness that is
typically used for load testing purposes only, and in this case would print the
password supplied by the user at the beginning of that test to document the
run. I don't think a substantial issue exists here.
Thanks again for the report.
> Trivial but potential security issue?
> --
>
> Key: CASSANDRA-13763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13763
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent github mirror, I've found the following line.
> Path: tools/stress/src/org/apache/cassandra/stress/settings/SettingsMode.java
> {code:java}
> 177 out.printf(" Password: %s%n",
> (password==null?password:"*suppressed*"));
> {code}
> As the original password is intended to be masked as "*suppressed *", I was
> wondering if showing "null" when the password is null is safe. This might not
> be an issue but I wanted to report just in case. Thanks!
--
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-13766) Invalid page state caused by IllegalArgumentException from ByteBuffer.limit()
[
https://issues.apache.org/jira/browse/CASSANDRA-13766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-13766:
-
Component/s: (was: Legacy/Core)
Local/SSTable
> Invalid page state caused by IllegalArgumentException from ByteBuffer.limit()
> -
>
> Key: CASSANDRA-13766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13766
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Jay Zhuang
>Priority: Minor
>
> Here is the exception:
> {noformat}
> ERROR [SharedPool-Worker-5] 2017-08-15 22:53:37,255 ErrorMessage.java:349 -
> Unexpected exception during request
> java.lang.IllegalArgumentException: null
> at java.nio.Buffer.limit(Buffer.java:275) ~[na:1.8.0_121]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:613)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytesWithShortLength(ByteBufferUtil.java:622)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:201)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.LegacyLayout.decodeClustering(LegacyLayout.java:326)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:242)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadCommand(SinglePartitionPager.java:73)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:68)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:34)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:315)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:351)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:227)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:494)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:471)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:131)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.1.0.CR6.jar:4.1.0.CR6]
> at
> io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> [netty-all-4.1.0.CR6.jar:4.1.0.CR6]
> at
> io.netty.channel.DefaultChannelHandlerInvoker$7.run(DefaultChannelHandlerInvoker.java:159)
> [netty-all-4.1.0.CR6.jar:4.1.0.CR6]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_121]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {noformat}
--
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-13558) WHERE or LIMIT clause with COPY TO and COPY FROM command
[ https://issues.apache.org/jira/browse/CASSANDRA-13558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-13558: - Component/s: (was: Legacy/CQL) Tool/cqlsh > WHERE or LIMIT clause with COPY TO and COPY FROM command > > > Key: CASSANDRA-13558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13558 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Deepak Patel >Priority: Minor > > COPY TO and COPY FROM commands are very useful and developer friendly. It > would be really nice to see where condition/limit clause supported with COPY > command. -- 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] [Resolved] (CASSANDRA-13763) Trivial but potential security issue?
[
https://issues.apache.org/jira/browse/CASSANDRA-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas resolved CASSANDRA-13763.
--
Resolution: Not A Problem
> Trivial but potential security issue?
> --
>
> Key: CASSANDRA-13763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13763
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent github mirror, I've found the following line.
> Path: tools/stress/src/org/apache/cassandra/stress/settings/SettingsMode.java
> {code:java}
> 177 out.printf(" Password: %s%n",
> (password==null?password:"*suppressed*"));
> {code}
> As the original password is intended to be masked as "*suppressed *", I was
> wondering if showing "null" when the password is null is safe. This might not
> be an issue but I wanted to report just in case. Thanks!
--
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-13763) Trivial but potential security issue?
[
https://issues.apache.org/jira/browse/CASSANDRA-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770229#comment-16770229
]
C. Scott Andreas commented on CASSANDRA-13763:
--
Thanks for reaching out, and sorry for the delay in reply to your question.
This code is part of the cassandra-stress tool, a benchmarking harness that is
typically used for load testing purposes only, and in this case would print the
password supplied by the user at the beginning of that test to document the
run. I don't think a substantial issue exists here.
Thanks again for the report.
> Trivial but potential security issue?
> --
>
> Key: CASSANDRA-13763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13763
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent github mirror, I've found the following line.
> Path: tools/stress/src/org/apache/cassandra/stress/settings/SettingsMode.java
> {code:java}
> 177 out.printf(" Password: %s%n",
> (password==null?password:"*suppressed*"));
> {code}
> As the original password is intended to be masked as "*suppressed *", I was
> wondering if showing "null" when the password is null is safe. This might not
> be an issue but I wanted to report just in case. Thanks!
--
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-13895) IOException unwrapping in CommitLogReader. readCommitLogSegment misses exceptions in resource creation block
[
https://issues.apache.org/jira/browse/CASSANDRA-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-13895:
-
Reproduced In: 3.11.0
> IOException unwrapping in CommitLogReader. readCommitLogSegment misses
> exceptions in resource creation block
>
>
> Key: CASSANDRA-13895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13895
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Catalin Grigoroscuta
>Priority: Minor
>
> CommitLogReader. readCommitLogSegment is unwrapping IOExceptions wrapped as
> RuntimeExceptions using a try-with-resource block.
> However, the resource specification block, {{RandomAccessReader reader =
> RandomAccessReader.open(file)}}, could also throw such an exception, which is
> missed by the catch block and throws as a RuntimeException instead of an
> IOException.
> One such example that I've seen is:
> - RandomAccessReader.open (called in try-with-resource resource specification
> block initialization)
> - ChannelProxy(File) constructor
> - ChannelProxy.openChannel (wraps IOException as RuntimeException)
> I don't know what the impact in Cassandra could be, I ran into this while
> processing CDC/commit logs for synchronization with another system.
> Was using Cassandra 3.11.0
--
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-14235) ReadFailure Error -- Large Unbound Query
[
https://issues.apache.org/jira/browse/CASSANDRA-14235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14235:
-
Reproduced In: 3.11.1
> ReadFailure Error -- Large Unbound Query
> -
>
> Key: CASSANDRA-14235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14235
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Environment: My instance of Cassandra is a single local node. It was
> installed via a tar file, versus installing it as a service. All settings are
> default.
> I'm operating on a Centos 7 machine (release 7.4.1708)
>Reporter: Fraizier
>Priority: Major
> Labels: newbie
>
> Receiving ReadFailure Error when executing 'select' query with cassandra
> python-driver.
> I have a keyspace called "Documents" and a table with two columns, name and
> object. Name is the text datatype and object is the blob datatype. The blob
> objects are pickled python class instances. The description of the
> keyspace/table is as follows:
>
> {code:java}
> CREATE TABLE "Documents".table (
> name text PRIMARY KEY,
> object blob
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment
> = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0 AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
>
> There are 3509 rows contained within this table and each object is approx.
> 25kb of data. (so I'm estimating ~90Mb of data in the object column.) I'm
> attempting to run a simple line of python cassandra code :
> {code:java}
> rows = session.execute("SELECT name, object FROM table")
> {code}
> and in the log file of cassandra this is what is produced:
> {code:java}
> WARN [ReadStage-4] 2018-02-13 14:53:12,319
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,10,main]: {}
> java.lang.RuntimeException: java.lang.RuntimeException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_151]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
[jira] [Updated] (CASSANDRA-14587) TrueDiskSpaceUsed overcounts snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-14587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14587: - Component/s: (was: Legacy/Tools) Tool/nodetool > TrueDiskSpaceUsed overcounts snapshots > -- > > Key: CASSANDRA-14587 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14587 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool > Environment: Debian 8 > Cassandra 3.11.2 >Reporter: Elliott Sims >Priority: Trivial > > Running 'nodetool listsnapshots' seems to overcount "TrueDiskSpaceUsed" under > some circumstances. Specifically when there's a large number of snapshots. > I suspect that it's not deduplicating space used when multiple snapshots > share sstables that are not part of the current table. > Results of "nodetool listsnapshots": > Total TrueDiskSpaceUsed: 396.11 MiB > Results of "du -hcs" on the table's directory: > 18M total > This is 50+ snapshots (every minute) run with "-t -sf > --column-family " > The results of a "du -hcs -L "TrueDiskSpaceUsed" > I have only tested against 3.11.2, but have no reason to believe it's unique > to that version or even 3.x. -- 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-13895) IOException unwrapping in CommitLogReader. readCommitLogSegment misses exceptions in resource creation block
[
https://issues.apache.org/jira/browse/CASSANDRA-13895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-13895:
-
Component/s: (was: Legacy/Core)
Local/Commit Log
> IOException unwrapping in CommitLogReader. readCommitLogSegment misses
> exceptions in resource creation block
>
>
> Key: CASSANDRA-13895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13895
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Catalin Grigoroscuta
>Priority: Minor
>
> CommitLogReader. readCommitLogSegment is unwrapping IOExceptions wrapped as
> RuntimeExceptions using a try-with-resource block.
> However, the resource specification block, {{RandomAccessReader reader =
> RandomAccessReader.open(file)}}, could also throw such an exception, which is
> missed by the catch block and throws as a RuntimeException instead of an
> IOException.
> One such example that I've seen is:
> - RandomAccessReader.open (called in try-with-resource resource specification
> block initialization)
> - ChannelProxy(File) constructor
> - ChannelProxy.openChannel (wraps IOException as RuntimeException)
> I don't know what the impact in Cassandra could be, I ran into this while
> processing CDC/commit logs for synchronization with another system.
> Was using Cassandra 3.11.0
--
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-13921) Unable to start Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-13921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770227#comment-16770227 ] C. Scott Andreas commented on CASSANDRA-13921: -- Hi [~rameshsraj], sorry for the delay in my reply. This bug tracker is used by the developers of Apache Cassandra to track development itself. If you are still experiencing this issue, could you reach out to the User's list or IRC channel as described here? Thanks! http://cassandra.apache.org/community/ > Unable to start Cassandra > - > > Key: CASSANDRA-13921 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13921 > Project: Cassandra > Issue Type: Test > Components: Legacy/Testing > Environment: CentOS Linux release 7.2.1511 (Core) > I am unable to start the cassandra and getting the below error: >Reporter: Ramesh S Raj >Priority: Major > > [root@btpvm0603 sbin]# ./cassandra -R > [root@btpvm0603 sbin]# > [root@btpvm0603 sbin]# CompilerOracle: dontinline > org/apache/cassandra/db/Columns$Serializer.deserializeLargeSubset > (Lorg/apache/cassandra/io/util/DataInputPlus;Lorg/apache/cassandra/db/Columns;I)Lorg/apache/cassandra/db/Columns; > CompilerOracle: dontinline > org/apache/cassandra/db/Columns$Serializer.serializeLargeSubset > (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;ILorg/apache/cassandra/io/util/DataOutputPlus;)V > CompilerOracle: dontinline > org/apache/cassandra/db/Columns$Serializer.serializeLargeSubsetSize > (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;I)I > CompilerOracle: dontinline > org/apache/cassandra/db/commitlog/AbstractCommitLogSegmentManager.advanceAllocatingFrom > (Lorg/apache/cassandra/db/commitlog/CommitLogSegment;)V > CompilerOracle: dontinline > org/apache/cassandra/db/transform/BaseIterator.tryGetMoreContents ()Z > CompilerOracle: dontinline > org/apache/cassandra/db/transform/StoppingTransformation.stop ()V > CompilerOracle: dontinline > org/apache/cassandra/db/transform/StoppingTransformation.stopInPartition ()V > CompilerOracle: dontinline > org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.doFlush (I)V > CompilerOracle: dontinline > org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeExcessSlow ()V > CompilerOracle: dontinline > org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeSlow (JI)V > CompilerOracle: dontinline > org/apache/cassandra/io/util/RebufferingInputStream.readPrimitiveSlowly (I)J > CompilerOracle: inline > org/apache/cassandra/db/rows/UnfilteredSerializer.serializeRowBody > (Lorg/apache/cassandra/db/rows/Row;ILorg/apache/cassandra/db/SerializationHeader;Lorg/apache/cassandra/io/util/DataOutputPlus;)V > CompilerOracle: inline org/apache/cassandra/io/util/Memory.checkBounds (JJ)V > CompilerOracle: inline org/apache/cassandra/io/util/SafeMemory.checkBounds > (JJ)V > CompilerOracle: inline > org/apache/cassandra/utils/AsymmetricOrdering.selectBoundary > (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;II)I > CompilerOracle: inline > org/apache/cassandra/utils/AsymmetricOrdering.strictnessOfLessThan > (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;)I > CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.indexes > (Lorg/apache/cassandra/utils/IFilter/FilterKey;)[J > CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.setIndexes > (JJIJ[J)V > CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare > (Ljava/nio/ByteBuffer;[B)I > CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare > ([BLjava/nio/ByteBuffer;)I > CompilerOracle: inline > org/apache/cassandra/utils/ByteBufferUtil.compareUnsigned > (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I > CompilerOracle: inline > org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo > (Ljava/lang/Object;JILjava/lang/Object;JI)I > CompilerOracle: inline > org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo > (Ljava/lang/Object;JILjava/nio/ByteBuffer;)I > CompilerOracle: inline > org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo > (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I > CompilerOracle: inline org/apache/cassandra/utils/vint/VIntCoding.encodeVInt > (JI)[B > [root@btpvm0603 sbin]# Error: A JNI error has occurred, please check your > installation and try again > Exception in thread "main" java.lang.NoClassDefFoundError: > org/yaml/snakeyaml/introspector/PropertyUtils > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.privateGetMethodRecursive(Class.java:3048) > at java.lang.Class.getMethod0(Class.java:3018) > at java.lang.Class.getMethod(Class.java:1784) > at >
[jira] [Resolved] (CASSANDRA-13921) Unable to start Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-13921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas resolved CASSANDRA-13921. -- Resolution: Information Provided > Unable to start Cassandra > - > > Key: CASSANDRA-13921 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13921 > Project: Cassandra > Issue Type: Test > Components: Legacy/Testing > Environment: CentOS Linux release 7.2.1511 (Core) > I am unable to start the cassandra and getting the below error: >Reporter: Ramesh S Raj >Priority: Major > > [root@btpvm0603 sbin]# ./cassandra -R > [root@btpvm0603 sbin]# > [root@btpvm0603 sbin]# CompilerOracle: dontinline > org/apache/cassandra/db/Columns$Serializer.deserializeLargeSubset > (Lorg/apache/cassandra/io/util/DataInputPlus;Lorg/apache/cassandra/db/Columns;I)Lorg/apache/cassandra/db/Columns; > CompilerOracle: dontinline > org/apache/cassandra/db/Columns$Serializer.serializeLargeSubset > (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;ILorg/apache/cassandra/io/util/DataOutputPlus;)V > CompilerOracle: dontinline > org/apache/cassandra/db/Columns$Serializer.serializeLargeSubsetSize > (Ljava/util/Collection;ILorg/apache/cassandra/db/Columns;I)I > CompilerOracle: dontinline > org/apache/cassandra/db/commitlog/AbstractCommitLogSegmentManager.advanceAllocatingFrom > (Lorg/apache/cassandra/db/commitlog/CommitLogSegment;)V > CompilerOracle: dontinline > org/apache/cassandra/db/transform/BaseIterator.tryGetMoreContents ()Z > CompilerOracle: dontinline > org/apache/cassandra/db/transform/StoppingTransformation.stop ()V > CompilerOracle: dontinline > org/apache/cassandra/db/transform/StoppingTransformation.stopInPartition ()V > CompilerOracle: dontinline > org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.doFlush (I)V > CompilerOracle: dontinline > org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeExcessSlow ()V > CompilerOracle: dontinline > org/apache/cassandra/io/util/BufferedDataOutputStreamPlus.writeSlow (JI)V > CompilerOracle: dontinline > org/apache/cassandra/io/util/RebufferingInputStream.readPrimitiveSlowly (I)J > CompilerOracle: inline > org/apache/cassandra/db/rows/UnfilteredSerializer.serializeRowBody > (Lorg/apache/cassandra/db/rows/Row;ILorg/apache/cassandra/db/SerializationHeader;Lorg/apache/cassandra/io/util/DataOutputPlus;)V > CompilerOracle: inline org/apache/cassandra/io/util/Memory.checkBounds (JJ)V > CompilerOracle: inline org/apache/cassandra/io/util/SafeMemory.checkBounds > (JJ)V > CompilerOracle: inline > org/apache/cassandra/utils/AsymmetricOrdering.selectBoundary > (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;II)I > CompilerOracle: inline > org/apache/cassandra/utils/AsymmetricOrdering.strictnessOfLessThan > (Lorg/apache/cassandra/utils/AsymmetricOrdering/Op;)I > CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.indexes > (Lorg/apache/cassandra/utils/IFilter/FilterKey;)[J > CompilerOracle: inline org/apache/cassandra/utils/BloomFilter.setIndexes > (JJIJ[J)V > CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare > (Ljava/nio/ByteBuffer;[B)I > CompilerOracle: inline org/apache/cassandra/utils/ByteBufferUtil.compare > ([BLjava/nio/ByteBuffer;)I > CompilerOracle: inline > org/apache/cassandra/utils/ByteBufferUtil.compareUnsigned > (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I > CompilerOracle: inline > org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo > (Ljava/lang/Object;JILjava/lang/Object;JI)I > CompilerOracle: inline > org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo > (Ljava/lang/Object;JILjava/nio/ByteBuffer;)I > CompilerOracle: inline > org/apache/cassandra/utils/FastByteOperations$UnsafeOperations.compareTo > (Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)I > CompilerOracle: inline org/apache/cassandra/utils/vint/VIntCoding.encodeVInt > (JI)[B > [root@btpvm0603 sbin]# Error: A JNI error has occurred, please check your > installation and try again > Exception in thread "main" java.lang.NoClassDefFoundError: > org/yaml/snakeyaml/introspector/PropertyUtils > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.privateGetMethodRecursive(Class.java:3048) > at java.lang.Class.getMethod0(Class.java:3018) > at java.lang.Class.getMethod(Class.java:1784) > at > sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) > at > sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) > Caused by: java.lang.ClassNotFoundException: > org.yaml.snakeyaml.introspector.PropertyUtils > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at
[jira] [Updated] (CASSANDRA-14351) Support systemd SD_NOTIFY interface during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-14351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14351:
-
Component/s: (was: Legacy/Core)
Packaging
> Support systemd SD_NOTIFY interface during startup
> --
>
> Key: CASSANDRA-14351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14351
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Thomas Bechtold
>Priority: Major
>
> When cassandra is started via systemd, it would be nice to support the
> [SD_NOTIFY|https://www.freedesktop.org/software/systemd/man/sd_notify.html]
> protocol so systemd know, when cassandra is ready (that can be use for
> dependencies or when you need to wait until cassandra startup is done).
> A very simple implementation could be done using the
> {code:java}
> systemd-notify --ready
> {code}
> command line tool (and ignore it if the tool is not there)
--
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-14235) ReadFailure Error -- Large Unbound Query
[
https://issues.apache.org/jira/browse/CASSANDRA-14235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14235:
-
Fix Version/s: (was: 3.11.1)
> ReadFailure Error -- Large Unbound Query
> -
>
> Key: CASSANDRA-14235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14235
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Environment: My instance of Cassandra is a single local node. It was
> installed via a tar file, versus installing it as a service. All settings are
> default.
> I'm operating on a Centos 7 machine (release 7.4.1708)
>Reporter: Fraizier
>Priority: Major
> Labels: newbie
>
> Receiving ReadFailure Error when executing 'select' query with cassandra
> python-driver.
> I have a keyspace called "Documents" and a table with two columns, name and
> object. Name is the text datatype and object is the blob datatype. The blob
> objects are pickled python class instances. The description of the
> keyspace/table is as follows:
>
> {code:java}
> CREATE TABLE "Documents".table (
> name text PRIMARY KEY,
> object blob
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment
> = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0 AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
>
> There are 3509 rows contained within this table and each object is approx.
> 25kb of data. (so I'm estimating ~90Mb of data in the object column.) I'm
> attempting to run a simple line of python cassandra code :
> {code:java}
> rows = session.execute("SELECT name, object FROM table")
> {code}
> and in the log file of cassandra this is what is produced:
> {code:java}
> WARN [ReadStage-4] 2018-02-13 14:53:12,319
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,10,main]: {}
> java.lang.RuntimeException: java.lang.RuntimeException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_151]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
[jira] [Updated] (CASSANDRA-14235) ReadFailure Error -- Large Unbound Query
[
https://issues.apache.org/jira/browse/CASSANDRA-14235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14235:
-
Component/s: (was: Legacy/CQL)
Messaging/Client
> ReadFailure Error -- Large Unbound Query
> -
>
> Key: CASSANDRA-14235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14235
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Environment: My instance of Cassandra is a single local node. It was
> installed via a tar file, versus installing it as a service. All settings are
> default.
> I'm operating on a Centos 7 machine (release 7.4.1708)
>Reporter: Fraizier
>Priority: Major
> Labels: newbie
> Fix For: 3.11.1
>
>
> Receiving ReadFailure Error when executing 'select' query with cassandra
> python-driver.
> I have a keyspace called "Documents" and a table with two columns, name and
> object. Name is the text datatype and object is the blob datatype. The blob
> objects are pickled python class instances. The description of the
> keyspace/table is as follows:
>
> {code:java}
> CREATE TABLE "Documents".table (
> name text PRIMARY KEY,
> object blob
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment
> = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0 AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
>
> There are 3509 rows contained within this table and each object is approx.
> 25kb of data. (so I'm estimating ~90Mb of data in the object column.) I'm
> attempting to run a simple line of python cassandra code :
> {code:java}
> rows = session.execute("SELECT name, object FROM table")
> {code}
> and in the log file of cassandra this is what is produced:
> {code:java}
> WARN [ReadStage-4] 2018-02-13 14:53:12,319
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,10,main]: {}
> java.lang.RuntimeException: java.lang.RuntimeException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_151]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.lang.RuntimeException: null
> at
> org.apache.cassandra.io.util.DataOutputBuffer.validateReallocation(DataOutputBuffer.java:134)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.calculateNewSize(DataOutputBuffer.java:152)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
>
[jira] [Updated] (CASSANDRA-14658) Cassandra hangs at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14658:
-
Component/s: Local/Commit Log
> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Jing Weng
>Priority: Major
> Fix For: 3.11.1
>
>
> Some time ago, when our cassandra cluster started, we found that it could not
> be started, checked various logs, and found no error message. Later, we
> obtained the thread stack information at startup by some means, and then
> refer to the source code, and found that if the commitlog initialization
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>
> {noformat}
> {
> "waitedCount": 0,
> "lockOwnerId": -1,
> "lockedMonitors": [],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "RUNNABLE",
> "inNative": false,
> "suspended": false,
> "threadName": "COMMIT-LOG-ALLOCATOR",
> "lockInfo": null,
> "threadId": 36,
> "stackTrace": [
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "runMayThrow",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
> "lineNumber": 133
> },
> {
> "fileName": "WrappedRunnable.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "org.apache.cassandra.utils.WrappedRunnable",
> "lineNumber": 28
> },
> {
> "fileName": "NamedThreadFactory.java",
> "nativeMethod": false,
> "methodName": "lambda$threadLocalDeallocator$0",
> "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
> "lineNumber": 81
> },
> {
> "fileName": null,
> "nativeMethod": false,
> "methodName": "run",
> "className":
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
> "lineNumber": -1
> },
> {
> "fileName": "Thread.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "java.lang.Thread",
> "lineNumber": 748
> }
> ],
> "blockedTime": -1,
> "lockName": null,
> "lockOwnerName": null,
> "lockedSynchronizers": []
> }{noformat}
>
> The thread stack of main thread:
>
> {noformat}
> {
> "waitedCount": 2,
> "lockOwnerId": -1,
> "lockedMonitors": [
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 10,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
> }
> },
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 11,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
> }
> },
> {
> "identityHashCode": 1087037934,
> "lockedStackDepth": 15,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
> }
> }
> ],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "WAITING",
> "inNative": false,
> "suspended": false,
> "threadName": "main",
> "lockInfo": null,
> "threadId": 1,
> "stackTrace": [
> {
> "fileName": "Unsafe.java",
> "nativeMethod": true,
> "methodName": "park",
> "className": "sun.misc.Unsafe",
> "lineNumber": -2
> },
> {
> "fileName": "LockSupport.java",
> "nativeMethod": false,
> "methodName": "park",
> "className": "java.util.concurrent.locks.LockSupport",
> "lineNumber": 304
> },
> {
> "fileName": "WaitQueue.java",
> "nativeMethod": false,
> "methodName": "awaitUninterruptibly",
> "className":
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
> "lineNumber": 280
> },
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "awaitAvailableSegment",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
>
[jira] [Commented] (CASSANDRA-14676) Use joins and aggregate functions in cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-14676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770218#comment-16770218 ] C. Scott Andreas commented on CASSANDRA-14676: -- Hi [~rk0589], sorry for the delay in my reply. Cassandra has limited support for user-defined aggregations. See here for documentation contributed by members of the community: [https://www.instaclustr.com/user-defined-functions-and-aggregates/]. As a non-relational database, joins are not supported though many join-related use cases can be met via denormalized data models. I should mention that this bug tracker is used by developers of Apache Cassandra. The best avenue for help is via the user's list or IRC channel. Details on these are available here: http://cassandra.apache.org/community/ > Use joins and aggregate functions in cassandra > -- > > Key: CASSANDRA-14676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14676 > Project: Cassandra > Issue Type: Wish > Components: Legacy/Testing >Reporter: Rama Krishna >Priority: Major > Fix For: 3.11.2 > > > Team, > > I am using Apache Cassandra 3.11.2 version , apart from Spark , do we have > any other alternative to use Joins and Aggregate functions in cassandra . > > > Thanks, > RK. -- 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-14669) Transient Replication: Confirm vnode support w/Transient Replication
[ https://issues.apache.org/jira/browse/CASSANDRA-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14669: - Component/s: (was: Legacy/Core) Feature/Transient Replication > Transient Replication: Confirm vnode support w/Transient Replication > > > Key: CASSANDRA-14669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14669 > Project: Cassandra > Issue Type: Sub-task > Components: Feature/Transient Replication >Reporter: Ariel Weisberg >Priority: Major > Fix For: 4.0.x > > > Transient replication's implementation supports vnodes, but the test coverage > is insufficient to be confident there are no hidden issues. Once test > coverage is sufficient we should allow the creation of TR keyspaces with > vnodes. -- 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-14676) Use joins and aggregate functions in cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-14676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14676: - Component/s: (was: Legacy/Testing) Feature/UDA > Use joins and aggregate functions in cassandra > -- > > Key: CASSANDRA-14676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14676 > Project: Cassandra > Issue Type: Wish > Components: Feature/UDA >Reporter: Rama Krishna >Priority: Major > Fix For: 3.11.2 > > > Team, > > I am using Apache Cassandra 3.11.2 version , apart from Spark , do we have > any other alternative to use Joins and Aggregate functions in cassandra . > > > Thanks, > RK. -- 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-14364) Update Seed provider documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-14364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14364: - Component/s: (was: Legacy/Documentation and Website) Documentation/Website > Update Seed provider documentation > -- > > Key: CASSANDRA-14364 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14364 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Ben Bromhead >Priority: Trivial > > Update documentation to describe how Cassandra uses the seed list. Include > details about nuances of using DNS hostnames vs IP addresses. > > [http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html#seed-provider] > -- 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-14508) Jenkins Slave doesn't have permission to write to /tmp/ directory
[
https://issues.apache.org/jira/browse/CASSANDRA-14508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14508:
-
Component/s: (was: Legacy/Testing)
Build
> Jenkins Slave doesn't have permission to write to /tmp/ directory
> -
>
> Key: CASSANDRA-14508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14508
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Jay Zhuang
>Priority: Major
>
> Which is causing uTest failed, e.g.:
> https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-test/lastCompletedBuild/testReport/org.apache.cassandra.streaming.compression/CompressedInputStreamTest/testCompressedReadUncompressedChunks/
> h3. Error Message
> {noformat}
> java.nio.file.AccessDeniedException: /tmp/na-1-big-Data.db
> {noformat}
> h3. Stacktrace
> {noformat}
> java.lang.RuntimeException: java.nio.file.AccessDeniedException:
> /tmp/na-1-big-Data.db at
> org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:119)
> at
> org.apache.cassandra.io.util.SequentialWriter.(SequentialWriter.java:141)
> at
> org.apache.cassandra.io.compress.CompressedSequentialWriter.(CompressedSequentialWriter.java:82)
> at
> org.apache.cassandra.streaming.compression.CompressedInputStreamTest.testCompressedReadWith(CompressedInputStreamTest.java:118)
> at
> org.apache.cassandra.streaming.compression.CompressedInputStreamTest.testCompressedReadUncompressedChunks(CompressedInputStreamTest.java:83)
> Caused by: java.nio.file.AccessDeniedException: /tmp/na-1-big-Data.db at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
> at java.nio.channels.FileChannel.open(FileChannel.java:287) at
> java.nio.channels.FileChannel.open(FileChannel.java:335) at
> org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:100)
> {noformat}
--
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-14533) Frozen Collections should allow TTL and WRITETIME access
[
https://issues.apache.org/jira/browse/CASSANDRA-14533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14533:
-
Component/s: (was: Legacy/CQL)
CQL/Interpreter
> Frozen Collections should allow TTL and WRITETIME access
>
>
> Key: CASSANDRA-14533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14533
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Scott Carey
>Priority: Major
>
> It is clear why we can not simply access ttl and writetime of normal
> collections, as the collection itself is made up of multiple cells (see
> CASSANDRA-8877)
>
> But frozen collections should allow it, since they are just one cell with the
> whole collection stored in a simple blob.
>
> Right now, I get an error message whether it is frozen or not:
>
> {noformat}
> cqlsh:testing> create table stuff (id int primary key, blah text, stuff
> frozen>);
> cqlsh:testing> insert into stuff (id, blah, stuff) VALUES (1, 'blargh', {
> 'setstuff' });
> cqlsh:testing> select id, blah, writetime(blah) from stuff;
> id | blah | writetime(blah)
> ++--
> 1 | blargh | 1529512132503886
> (1 rows)
> cqlsh:testing> select id, stuff, writetime(stuff) from stuff;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> use selection function writeTime on collections"
> cqlsh:testing> select id, stuff from stuff;
> id | stuff
> +--
> 1 | {'setstuff'}{noformat}
>
> It is likewise not possible to get the timestamp on a frozen collection from
> the java client.
--
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-14582) Add a system property to set the cassandra hostId if not yet initialized
[ https://issues.apache.org/jira/browse/CASSANDRA-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14582: - Fix Version/s: (was: 3.11.x) (was: 4.x) > Add a system property to set the cassandra hostId if not yet initialized > > > Key: CASSANDRA-14582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14582 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: vincent royer >Priority: Minor > > Add a system property *cassandra.host_id* to set the cassandra hostId if not > yet initialized. > This allow to push the cassandra host ID when provisioning new cassandra > nodes rather than to retreive it after the first start. -- 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-14658) Cassandra hangs at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14658:
-
Reproduced In: 3.11.1
> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Jing Weng
>Priority: Major
>
> Some time ago, when our cassandra cluster started, we found that it could not
> be started, checked various logs, and found no error message. Later, we
> obtained the thread stack information at startup by some means, and then
> refer to the source code, and found that if the commitlog initialization
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>
> {noformat}
> {
> "waitedCount": 0,
> "lockOwnerId": -1,
> "lockedMonitors": [],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "RUNNABLE",
> "inNative": false,
> "suspended": false,
> "threadName": "COMMIT-LOG-ALLOCATOR",
> "lockInfo": null,
> "threadId": 36,
> "stackTrace": [
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "runMayThrow",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
> "lineNumber": 133
> },
> {
> "fileName": "WrappedRunnable.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "org.apache.cassandra.utils.WrappedRunnable",
> "lineNumber": 28
> },
> {
> "fileName": "NamedThreadFactory.java",
> "nativeMethod": false,
> "methodName": "lambda$threadLocalDeallocator$0",
> "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
> "lineNumber": 81
> },
> {
> "fileName": null,
> "nativeMethod": false,
> "methodName": "run",
> "className":
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
> "lineNumber": -1
> },
> {
> "fileName": "Thread.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "java.lang.Thread",
> "lineNumber": 748
> }
> ],
> "blockedTime": -1,
> "lockName": null,
> "lockOwnerName": null,
> "lockedSynchronizers": []
> }{noformat}
>
> The thread stack of main thread:
>
> {noformat}
> {
> "waitedCount": 2,
> "lockOwnerId": -1,
> "lockedMonitors": [
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 10,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
> }
> },
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 11,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
> }
> },
> {
> "identityHashCode": 1087037934,
> "lockedStackDepth": 15,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
> }
> }
> ],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "WAITING",
> "inNative": false,
> "suspended": false,
> "threadName": "main",
> "lockInfo": null,
> "threadId": 1,
> "stackTrace": [
> {
> "fileName": "Unsafe.java",
> "nativeMethod": true,
> "methodName": "park",
> "className": "sun.misc.Unsafe",
> "lineNumber": -2
> },
> {
> "fileName": "LockSupport.java",
> "nativeMethod": false,
> "methodName": "park",
> "className": "java.util.concurrent.locks.LockSupport",
> "lineNumber": 304
> },
> {
> "fileName": "WaitQueue.java",
> "nativeMethod": false,
> "methodName": "awaitUninterruptibly",
> "className":
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
> "lineNumber": 280
> },
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "awaitAvailableSegment",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
> "lineNumber": 262
> },
> {
>
[jira] [Updated] (CASSANDRA-14582) Add a system property to set the cassandra hostId if not yet initialized
[ https://issues.apache.org/jira/browse/CASSANDRA-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14582: - Component/s: (was: Local/Startup and Shutdown) Local/Config > Add a system property to set the cassandra hostId if not yet initialized > > > Key: CASSANDRA-14582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14582 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: vincent royer >Priority: Minor > Fix For: 3.11.x, 4.x > > > Add a system property *cassandra.host_id* to set the cassandra hostId if not > yet initialized. > This allow to push the cassandra host ID when provisioning new cassandra > nodes rather than to retreive it after the first start. -- 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-14658) Cassandra hangs at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14658:
-
Fix Version/s: (was: 3.11.1)
> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Jing Weng
>Priority: Major
>
> Some time ago, when our cassandra cluster started, we found that it could not
> be started, checked various logs, and found no error message. Later, we
> obtained the thread stack information at startup by some means, and then
> refer to the source code, and found that if the commitlog initialization
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>
> {noformat}
> {
> "waitedCount": 0,
> "lockOwnerId": -1,
> "lockedMonitors": [],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "RUNNABLE",
> "inNative": false,
> "suspended": false,
> "threadName": "COMMIT-LOG-ALLOCATOR",
> "lockInfo": null,
> "threadId": 36,
> "stackTrace": [
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "runMayThrow",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
> "lineNumber": 133
> },
> {
> "fileName": "WrappedRunnable.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "org.apache.cassandra.utils.WrappedRunnable",
> "lineNumber": 28
> },
> {
> "fileName": "NamedThreadFactory.java",
> "nativeMethod": false,
> "methodName": "lambda$threadLocalDeallocator$0",
> "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
> "lineNumber": 81
> },
> {
> "fileName": null,
> "nativeMethod": false,
> "methodName": "run",
> "className":
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
> "lineNumber": -1
> },
> {
> "fileName": "Thread.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "java.lang.Thread",
> "lineNumber": 748
> }
> ],
> "blockedTime": -1,
> "lockName": null,
> "lockOwnerName": null,
> "lockedSynchronizers": []
> }{noformat}
>
> The thread stack of main thread:
>
> {noformat}
> {
> "waitedCount": 2,
> "lockOwnerId": -1,
> "lockedMonitors": [
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 10,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
> }
> },
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 11,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
> }
> },
> {
> "identityHashCode": 1087037934,
> "lockedStackDepth": 15,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
> }
> }
> ],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "WAITING",
> "inNative": false,
> "suspended": false,
> "threadName": "main",
> "lockInfo": null,
> "threadId": 1,
> "stackTrace": [
> {
> "fileName": "Unsafe.java",
> "nativeMethod": true,
> "methodName": "park",
> "className": "sun.misc.Unsafe",
> "lineNumber": -2
> },
> {
> "fileName": "LockSupport.java",
> "nativeMethod": false,
> "methodName": "park",
> "className": "java.util.concurrent.locks.LockSupport",
> "lineNumber": 304
> },
> {
> "fileName": "WaitQueue.java",
> "nativeMethod": false,
> "methodName": "awaitUninterruptibly",
> "className":
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
> "lineNumber": 280
> },
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "awaitAvailableSegment",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
> "lineNumber": 262
> },
>
[jira] [Updated] (CASSANDRA-14658) Cassandra hangs at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14658:
-
Component/s: (was: Legacy/Core)
> Cassandra hangs at startup
> --
>
> Key: CASSANDRA-14658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14658
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jing Weng
>Priority: Major
> Fix For: 3.11.1
>
>
> Some time ago, when our cassandra cluster started, we found that it could not
> be started, checked various logs, and found no error message. Later, we
> obtained the thread stack information at startup by some means, and then
> refer to the source code, and found that if the commitlog initialization
> error occurs at startup, cassandra will appear deadlock and hang.
> The thread stack of COMMIT-LOG-ALLOCATOR:
>
> {noformat}
> {
> "waitedCount": 0,
> "lockOwnerId": -1,
> "lockedMonitors": [],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "RUNNABLE",
> "inNative": false,
> "suspended": false,
> "threadName": "COMMIT-LOG-ALLOCATOR",
> "lockInfo": null,
> "threadId": 36,
> "stackTrace": [
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "runMayThrow",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1",
> "lineNumber": 133
> },
> {
> "fileName": "WrappedRunnable.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "org.apache.cassandra.utils.WrappedRunnable",
> "lineNumber": 28
> },
> {
> "fileName": "NamedThreadFactory.java",
> "nativeMethod": false,
> "methodName": "lambda$threadLocalDeallocator$0",
> "className": "org.apache.cassandra.concurrent.NamedThreadFactory",
> "lineNumber": 81
> },
> {
> "fileName": null,
> "nativeMethod": false,
> "methodName": "run",
> "className":
> "org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4\/1392794732",
> "lineNumber": -1
> },
> {
> "fileName": "Thread.java",
> "nativeMethod": false,
> "methodName": "run",
> "className": "java.lang.Thread",
> "lineNumber": 748
> }
> ],
> "blockedTime": -1,
> "lockName": null,
> "lockOwnerName": null,
> "lockedSynchronizers": []
> }{noformat}
>
> The thread stack of main thread:
>
> {noformat}
> {
> "waitedCount": 2,
> "lockOwnerId": -1,
> "lockedMonitors": [
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 10,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 620
> }
> },
> {
> "identityHashCode": 600118828,
> "lockedStackDepth": 11,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "ColumnFamilyStore.java",
> "nativeMethod": false,
> "methodName": "createColumnFamilyStore",
> "className": "org.apache.cassandra.db.ColumnFamilyStore",
> "lineNumber": 594
> }
> },
> {
> "identityHashCode": 1087037934,
> "lockedStackDepth": 15,
> "className": "java.lang.Class",
> "lockedStackFrame": {
> "fileName": "Keyspace.java",
> "nativeMethod": false,
> "methodName": "open",
> "className": "org.apache.cassandra.db.Keyspace",
> "lineNumber": 127
> }
> }
> ],
> "waitedTime": -1,
> "blockedCount": 0,
> "threadState": "WAITING",
> "inNative": false,
> "suspended": false,
> "threadName": "main",
> "lockInfo": null,
> "threadId": 1,
> "stackTrace": [
> {
> "fileName": "Unsafe.java",
> "nativeMethod": true,
> "methodName": "park",
> "className": "sun.misc.Unsafe",
> "lineNumber": -2
> },
> {
> "fileName": "LockSupport.java",
> "nativeMethod": false,
> "methodName": "park",
> "className": "java.util.concurrent.locks.LockSupport",
> "lineNumber": 304
> },
> {
> "fileName": "WaitQueue.java",
> "nativeMethod": false,
> "methodName": "awaitUninterruptibly",
> "className":
> "org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal",
> "lineNumber": 280
> },
> {
> "fileName": "AbstractCommitLogSegmentManager.java",
> "nativeMethod": false,
> "methodName": "awaitAvailableSegment",
> "className":
> "org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager",
> "lineNumber": 262
> },
>
[jira] [Resolved] (CASSANDRA-14676) Use joins and aggregate functions in cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-14676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas resolved CASSANDRA-14676. -- Resolution: Information Provided > Use joins and aggregate functions in cassandra > -- > > Key: CASSANDRA-14676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14676 > Project: Cassandra > Issue Type: Wish > Components: Legacy/Testing >Reporter: Rama Krishna >Priority: Major > Fix For: 3.11.2 > > > Team, > > I am using Apache Cassandra 3.11.2 version , apart from Spark , do we have > any other alternative to use Joins and Aggregate functions in cassandra . > > > Thanks, > RK. -- 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-14771) Transient Replication: Writes at CL.ALL should block on all full replicas, but not transients
[ https://issues.apache.org/jira/browse/CASSANDRA-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14771: - Component/s: (was: Legacy/Coordination) Feature/Transient Replication > Transient Replication: Writes at CL.ALL should block on all full replicas, > but not transients > -- > > Key: CASSANDRA-14771 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14771 > Project: Cassandra > Issue Type: Bug > Components: Feature/Transient Replication >Reporter: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Reading at ONE will still be safe because ONE only selects full replicas. > There is no reason to write to transients if we are going to block on all > full replicas. -- 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-14816) Add Operating System Specific Setup Documentation for Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-14816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14816:
-
Component/s: (was: Legacy/Documentation and Website)
Documentation/Website
> Add Operating System Specific Setup Documentation for Cassandra
> ---
>
> Key: CASSANDRA-14816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14816
> Project: Cassandra
> Issue Type: Wish
> Components: Documentation/Website
>Reporter: Joseph Lynch
>Priority: Minor
>
> There are a number of operating system tunings that can vastly improve
> Cassandra's performance on Linux in particular things like:
> # Setting {{/sys/block/${DEVICE}/queue/read_ahead_kb}} to something more
> reasonable like 32
> # Setting the qdisc on modern linux to something better like {{tc-fq}} with
> {{bbr}}
> # Setting {{nofile}} ulimits properly and {{fs.file-max}}
> # Potentially raising {{vm.max_map_count}} even higher than the default
> debian package does
> # Using raid instead of jbod
> # Mounting /tmp on a tmpfs and turning back on {{PerfDisableSharedMem}}
> And many more ... I think many of the recommendations from [Amy
> Tobey's|https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html]
> 2.1 guide may still be pretty relevant.
> Perhaps we can document some of these in the website's Operations section?
--
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-14774) Upgrade of snappy java and JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14774: - Component/s: (was: Build) Dependencies > Upgrade of snappy java and JNA > -- > > Key: CASSANDRA-14774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14774 > Project: Cassandra > Issue Type: Wish > Components: Dependencies > Environment: Ubuntu, RHEL >Reporter: Nayana Thorat >Priority: Critical > Fix For: 3.11.x > > > We are building Apache Cassandra for s390x. We have observed that current > latest version 3.11.3 has snappy java 1.1.1.7 and JNA 4.2.2. > However these versions doesn't have s390x support. s390x support is available > in JNA 4.5.0 and snappy-java 1.1.2.6 > Is it possible to upgrade JNA from 4.2.2. to 4.5.0? > Also the snappy from 1.1.1.7 to 1.1.2.6? > Please let us know if you need more info. > > > -- 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-14982) PicklingError: Can't pickle : attribute lookup cqlshlib.copyutil.ImmutableDict failed
[
https://issues.apache.org/jira/browse/CASSANDRA-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770201#comment-16770201
]
C. Scott Andreas commented on CASSANDRA-14982:
--
Hi [~vaclavt], it looks like the size of the batch generated via your cqlsh
import is exceeding the max batch size configured in Cassandra. This is
controlled in cqlsh via MAXBATCHSIZE=x, and in cassandra.yaml via
batch_size_fail_threshold_in_kb.
To address this you can either specify a MAXBATCHSIZE in cqlsh by adding a low
limit such as "and MAXBATCHSIZE=10" to your COPY command, or via increasing the
max batch size server-side with batch_size_fail_threshold_in_kb to a value that
exceeds what would be imported by cqlsh on a per-batch basis.
Point taken re: the PicklingError and exit-0 status that's returned; thanks for
filing this.
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> --
>
> Key: CASSANDRA-14982
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14982
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
> Environment: cqlsh --version
> cqlsh 5.0.1
>
>Reporter: Vaclav
>Priority: Major
> Fix For: 3.11.3
>
>
> Hello
> I am trying to load records from file containing some very long lines (up to
> 180_000 characters). In some cases order of lines in file causes error
> 'Error from server: code=2200 [Invalid query] message="Batch too large"'
> catched and printed in copyutils.py, class SendingChanel in method feed(),
> but error is just printed, records are not loaded, no error file with
> unimported rows is created and import continues. cqlsh at the end returns
> code 0 even not all rows are imported. Even that number of imported rows is
> wrong, it shows number of records in file but in fact it loaded less records.
> So I cannot be sure, based on returned code, that copy command did load all
> rows. My problem is that in this case only way to find something went wrong
> and data are not loaded correctly is to watch for error message on screen,
> which is problem when this happens in very long import script (script loading
> many tables).
> I think when not all rows are loaded correctly return code should not be 0,
> or when records aren't loaded it should exit with error immediatelly.
> $ cqlsh 127.0.0.1 --request-timeout="3600" -e "copy woc.item_container from
> '/tmp/cexport/woc/item_container.csv' with escape='\"' and null=null and
> header=True"
> Reading options from the command line: \{'header': 'True', 'null': 'null',
> 'escape': '"'}
> Using 7 child processes
> Starting copy of woc.item_container with columns [container_id, capacity,
> classes, instances, owner_id, type].
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> PicklingError: Can't pickle :
> attribute lookup cqlshlib.copyutil.ImmutableDict failed
> Processed: 38420 rows; Rate: 7455 rows/s; Avg. rate: 6881 rows/s
> 38420 rows imported from 1 files in 5.584 seconds (0 skipped).
> $ echo $?
> 0
--
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-14941) Expired secondary index sstables are not promptly discarded under TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-14941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14941:
-
Reproduced In: 3.0.17
> Expired secondary index sstables are not promptly discarded under TWCS
> --
>
> Key: CASSANDRA-14941
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14941
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Samuel Klock
>Priority: Major
>
> We have a table in a cluster running 3.0.17 storing roughly time-series data
> using TWCS with a secondary index. We've noticed that while expired sstables
> for the table are discarded mostly when we expect them to be, the expired
> sstables for the secondary index would linger for weeks longer than expected
> – essentially indefinitely. Eventually the sstables would fill disks, which
> would require manual steps (deleting ancient index sstables) to address. We
> verified with {{sstableexpiredblockers}} that there wasn't anything on disk
> blocking the expired sstables from being dropped, so this looks like a bug.
> Through some debugging, we traced the problem to the index's memtables, which
> were consistently (except _just_ after node restarts) reporting a minimum
> timestamp from September 2015 – much older than any of our live data – which
> causes {{CompactionController.getFullyExpiredSSTables()}} to consistently
> return an empty set. The reason that the index sstables report this minimum
> timestamp is because of how index updates are created, using
> {{PartitionUpdate.singleRowUpdate()}}:
> {code:java}
> public static PartitionUpdate singleRowUpdate(CFMetaData metadata,
> DecoratedKey key, Row row, Row staticRow)
> {
> MutableDeletionInfo deletionInfo = MutableDeletionInfo.live();
> Holder holder = new Holder(
> new PartitionColumns(
> staticRow == null ? Columns.NONE :
> Columns.from(staticRow.columns()),
> row == null ? Columns.NONE : Columns.from(row.columns())
> ),
> row == null ? BTree.empty() : BTree.singleton(row),
> deletionInfo,
> staticRow == null ? Rows.EMPTY_STATIC_ROW : staticRow,
> EncodingStats.NO_STATS
> );
> return new PartitionUpdate(metadata, key, holder, deletionInfo,
> false);
> }
> {code}
> The use of {{EncodingStats.NO_STATS}} makes it appear as though the earliest
> timestamp in the resulting {{PartitionUpdate}} is from September 2015. That
> timestamp becomes the minimum for the memtable.
> Modifying this version of {{PartitionUpdate.singleRowUpdate()}} to:
> {code:java}
> public static PartitionUpdate singleRowUpdate(CFMetaData metadata,
> DecoratedKey key, Row row, Row staticRow)
> {
> MutableDeletionInfo deletionInfo = MutableDeletionInfo.live();
> staticRow = (staticRow == null ? Rows.EMPTY_STATIC_ROW : staticRow);
> EncodingStats stats = EncodingStats.Collector.collect(staticRow,
> (row == null ?
>
> Collections.emptyIterator() :
>
> Iterators.singletonIterator(row)),
> deletionInfo);
> Holder holder = new Holder(
> new PartitionColumns(
> staticRow == Rows.EMPTY_STATIC_ROW ? Columns.NONE :
> Columns.from(staticRow.columns()),
> row == null ? Columns.NONE : Columns.from(row.columns())
> ),
> row == null ? BTree.empty() : BTree.singleton(row),
> deletionInfo,
> staticRow,
> stats
> );
> return new PartitionUpdate(metadata, key, holder, deletionInfo,
> false);
> }
> {code}
> (i.e., computing an {{EncodingStats}} from the contents of the update) seems
> to fix the problem. However, we're not certain whether A) there's a
> functional reason the method was using {{EncodingStats.NO_STATS}} previously
> or B) whether the {{EncodingStats}} the revised version creates is correct
> (in particular, the use of {{deletionInfo}} feels a little suspect). We're
> also not sure whether there's a more appropriate fix (e.g., changing how the
> memtables compute the minimum timestamp, particularly in the {{NO_STATS}}
> case).
--
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-14774) Upgrade of snappy java and JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14774: - Priority: Minor (was: Critical) > Upgrade of snappy java and JNA > -- > > Key: CASSANDRA-14774 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14774 > Project: Cassandra > Issue Type: Wish > Components: Dependencies > Environment: Ubuntu, RHEL >Reporter: Nayana Thorat >Priority: Minor > Fix For: 3.11.x > > > We are building Apache Cassandra for s390x. We have observed that current > latest version 3.11.3 has snappy java 1.1.1.7 and JNA 4.2.2. > However these versions doesn't have s390x support. s390x support is available > in JNA 4.5.0 and snappy-java 1.1.2.6 > Is it possible to upgrade JNA from 4.2.2. to 4.5.0? > Also the snappy from 1.1.1.7 to 1.1.2.6? > Please let us know if you need more info. > > > -- 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-14853) Change default timestamp format to output only milliseconds, not microseconds
[
https://issues.apache.org/jira/browse/CASSANDRA-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14853:
-
Component/s: (was: Dependencies)
Tool/cqlsh
> Change default timestamp format to output only milliseconds, not microseconds
> -
>
> Key: CASSANDRA-14853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14853
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
> Environment: Reproduced in trunk
>Reporter: Alex Ott
>Priority: Major
> Labels: cqlsh
>
> By default cqlsh outputs the timestamp column with microseconds precision,
> like this:
> {noformat}
> cqlsh:test> create table t1(tm timestamp primary key, t text);
> cqlsh:test> insert into t1(tm, t) values(toTimestamp(now()), 't');
> cqlsh:test> insert into t1(tm, t) values(toTimestamp(now()), 't2');
> cqlsh:test> SELECT * from t1;
> tm | t
> -+
> 2018-10-27 18:01:54.738000+ | t2
> 2018-10-27 18:01:52.599000+ | t
> (2 rows)
> {noformat}
> But if I want to use the value that is output on the screen in my query, I
> get an error:
> {noformat}
> cqlsh:test> select * from t1 where tm = '2018-10-27 18:01:54.738000+';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Unable
> to coerce '2018-10-27 18:01:54.738000+' to a formatted date (long)"
> {noformat}
> But if I manually round it to milliseconds, then everything works:
> {noformat}
> cqlsh:test> select * from t1 where tm = '2018-10-27 18:01:54.738+';
> tm | t
> -+
> 2018-10-27 18:01:54.738000+ | t2
> (1 rows)
> {noformat}
> It would be much easier user's experience if we use the same format for
> output & input data, because right now this leads to errors, that often not
> really understandable by novice users.
> P.S. I know about cqlshrc, but not every user has it configured.
--
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-14994) Incorrect repair history when running repair
[
https://issues.apache.org/jira/browse/CASSANDRA-14994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14994:
-
Component/s: Consistency/Repair
> Incorrect repair history when running repair
>
>
> Key: CASSANDRA-14994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14994
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Olsson
>Priority: Minor
>
> Since CASSANDRA-5220 there is an issue with
> *system_distributed.repair_history* when using virtual nodes. Performing a
> standard "nodetool repair" will create a lot less entries than it should.
> Example:
> {code}
> $ ccm create test_repair -n 3 --vnodes -v 3.0.17
> ...
> cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> cqlsh> CREATE TABLE test.test(key PRIMARY KEY);
> ...
> ccm node1 nodetool repair test
> ...
> cqlsh> SELECT keyspace_name, columnfamily_name, id, range_begin, range_end
> FROM system_distributed.repair_history ;
> keyspace_name | columnfamily_name | id |
> range_begin | range_end
> ---+---+--+-+-
> test | test | 12f27830-1e53-11e9-93a0-2122ff85bd0a |
> 6842951316968308632 | 6844625844103123572
> {code}
> In the above example the cluster is created with 256 tokens but the repair
> history only shows one entry.
> The problem is that in CASSANDRA-5220 a single repair session can repair
> multiple token ranges but the insertion into the repair_history table is done
> with the same id for all of them.
--
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-14942) cqlsh cannot describe keyspace when having table schema extensions
[
https://issues.apache.org/jira/browse/CASSANDRA-14942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14942:
-
Component/s: (was: Legacy/CQL)
Tool/cqlsh
> cqlsh cannot describe keyspace when having table schema extensions
> --
>
> Key: CASSANDRA-14942
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14942
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
> Environment: Cassandra 3.11.3
> The issue comes from the cqlsh utility, in cassandra/metadata.py, function
> _all_as_cql, viewkeys is not known.
>
>
>Reporter: vincent royer
>Priority: Minor
> Labels: cqlsh
>
> When adding a schema table extension to a table, cqlsh failed to describe
> keyspace or table with the following error message: 'module' object has no
> attribute 'viewkeys'
> Step to reproduce the issue:
> {{docker run --name some-cassandra -d docker.io/cassandra:3.11.3}}{{docker
> exec -it cqlsh < {{CREATE KEYSPACE ks WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': 1};}}
> {{CREATE TABLE ks.cf (id text PRIMARY KEY , a int);}}
> {{INSERT INTO system_schema.tables (keyspace_name, table_name, extensions )
> VALUES ( 'ks','cf',\{'key1':textAsBlob('foo')});}}
> {{EOF}}
>
> {{docker exec -it cqlsh -e "DESC KEYSPACE ks"}}
> {{'module' object has no attribute 'viewkeys'}}
>
> docker exec -it c75a002959e2 cqlsh --debug -e "DESC KEYSPACE ks"
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/__init__.py'>
> Using connect timeout: 5 seconds
> Using 'utf-8' encoding
> Using ssl: False
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 925, in onecmd
> self.handle_statement(st, statementtext)
> File "/usr/bin/cqlsh.py", line 962, in handle_statement
> return custom_handler(parsed)
> File "/usr/bin/cqlsh.py", line 1545, in do_describe
> self.describe_keyspace(ksname)
> File "/usr/bin/cqlsh.py", line 1281, in describe_keyspace
> self.print_recreate_keyspace(self.get_keyspace_meta(ksname), sys.stdout)
> File "/usr/bin/cqlsh.py", line 1231, in print_recreate_keyspace
> out.write(ksdef.export_as_string())
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/metadata.py",
> line 661, in export_as_string
> + [t.export_as_string() for t in self.tables.values()])
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/metadata.py",
> line 1116, in export_as_string
> ret = self._all_as_cql()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/metadata.py",
> line 1135, in _all_as_cql
> for k in six.viewkeys(registry) & self.extensions: # no viewkeys on
> OrderedMapSerializeKey
> AttributeError: 'module' object has no attribute 'viewkeys'
>
--
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-14984) [dtest] 2 TestBootstrap tests failed for branch 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-14984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14984:
-
Reproduced In: 2.2.14
> [dtest] 2 TestBootstrap tests failed for branch 2.2
> ---
>
> Key: CASSANDRA-14984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14984
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Jay Zhuang
>Priority: Major
>
> Failed tests:
> {noformat}
> test_decommissioned_wiped_node_can_join
> test_decommissioned_wiped_node_can_gossip_to_single_seed
> {noformat}
> Error:
> {noformat}
> ...
> # Decommision the new node and kill it
> logger.debug("Decommissioning & stopping node2")
> > node2.decommission()
> ...
> def handle_external_tool_process(process, cmd_args):
> out, err = process.communicate()
> if (out is not None) and isinstance(out, bytes):
> out = out.decode()
> if (err is not None) and isinstance(err, bytes):
> err = err.decode()
> rc = process.returncode
> if rc != 0:
> > raise ToolError(cmd_args, rc, out, err)
> E ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost',
> '-p', '7200', 'decommission'] exited with non-zero status; exit status: 2;
> E stderr: error: Thread signal failed
> E -- StackTrace --
> E java.io.IOException: Thread signal failed
> {noformat}
--
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-14998) Support "validate only" option for `nodetool import`
[ https://issues.apache.org/jira/browse/CASSANDRA-14998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14998: - Component/s: Tool/nodetool > Support "validate only" option for `nodetool import` > > > Key: CASSANDRA-14998 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14998 > Project: Cassandra > Issue Type: New Feature > Components: Tool/bulk load, Tool/nodetool >Reporter: Doug Rohrer >Priority: Major > > In order to support safer import of data (especially in the face of nodetool > import now taking multiple directories as input completed in > CASSANDRA-14442), it would be good to be able to validate said data before > import as it is possible one or more SSTables may somehow have been corrupted > during transport. I'm not sure what the preferred way forward on this (add a > `nodetool verify-import` or perhaps `nodetool import --verify-only` as a > flag) but this would allow an end-user to prevent partial imports where some > of the data is good, and some is corrupt. -- 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-14998) Support "validate only" option for `nodetool import`
[ https://issues.apache.org/jira/browse/CASSANDRA-14998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14998: - Component/s: Tool/bulk load > Support "validate only" option for `nodetool import` > > > Key: CASSANDRA-14998 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14998 > Project: Cassandra > Issue Type: New Feature > Components: Tool/bulk load >Reporter: Doug Rohrer >Priority: Major > > In order to support safer import of data (especially in the face of nodetool > import now taking multiple directories as input completed in > CASSANDRA-14442), it would be good to be able to validate said data before > import as it is possible one or more SSTables may somehow have been corrupted > during transport. I'm not sure what the preferred way forward on this (add a > `nodetool verify-import` or perhaps `nodetool import --verify-only` as a > flag) but this would allow an end-user to prevent partial imports where some > of the data is good, and some is corrupt. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770171#comment-16770171 ] C. Scott Andreas edited comment on CASSANDRA-15020 at 2/16/19 6:50 PM: --- Thank you for reporting this, [~lucinda]! I've attached two small patches to fix this. One applies to trunk and the 3.11 branch (in which the .rst docs exist), and a second patch for the Textile documentation used for 3.0. was (Author: cscotta): Thank you for reporting this, [~lucinda]! I've attached two small patches to fix this. One applies to trunk and the 3.11 branch (in which the .rst docs exist), and a second patch for the Textile documentation used for 3.0.[^CASSANDRA-15020-trunk-3.11.patch] > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Assignee: C. Scott Andreas >Priority: Trivial > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- 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-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770171#comment-16770171 ] C. Scott Andreas commented on CASSANDRA-15020: -- Thank you for reporting this, [~lucinda]! I've attached two small patches to fix this. One applies to trunk and the 3.11 branch (in which the .rst docs exist), and a second patch for the Textile documentation used for 3.0.[^CASSANDRA-15020-trunk-3.11.patch] > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Priority: Trivial > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- 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-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15020: - Attachment: CASSANDRA-15020-3.0.patch CASSANDRA-15020-trunk-3.11.patch > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Priority: Trivial > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- 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-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15020: - Assignee: C. Scott Andreas Status: Patch Available (was: Open) > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Assignee: C. Scott Andreas >Priority: Trivial > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- 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-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770133#comment-16770133
]
C. Scott Andreas commented on CASSANDRA-15005:
--
Thanks for reaching out! +cc'ing [~jmeredithco] for visibility, who's begun
exploring some related work, too.
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Minor
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
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
