[jira] [Commented] (CASSANDRA-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864557#comment-16864557 ] arganzheng commented on CASSANDRA-15161: [~pedro_gordo] Thanks, I find that in that Page above the "Reporting bugs" Section, that's misleading. > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. > Thanks in advance. -- 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-15162) IndexNotAvailableException: The secondary index 'idx_ma_transaction_id' is not yet available
[
https://issues.apache.org/jira/browse/CASSANDRA-15162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-15162:
-
Resolution: Invalid
Status: Resolved (was: Triage Needed)
Please use the user mailing list or the Cassandra room in Slack for operations
questions. From first glance, this is just a matter of the index still being
built.
See http://cassandra.apache.org/doc/latest/contactus.html
> IndexNotAvailableException: The secondary index 'idx_ma_transaction_id' is
> not yet available
>
>
> Key: CASSANDRA-15162
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15162
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Pradip Kumar
>Priority: Normal
>
> Hi,
> I created an index on the table "moneyid_allocation" as below..
> *CREATE INDEX idx_ma_transaction_id ON moneymarking.moneyid_allocation
> (transaction_id);*
> But when I am selecting the data by using the indexed column the got error in
> the system.log, Please suggest to resolve the issue
> There are around 10 million records in the table.
>
> *select query:-*
> select * from moneyid_allocation where transaction_id='11' limit 1
> ALLOW FILTERING;
> *Error in system.log:-*
> WARN [ReadStage-4] 2019-06-14 23:28:56,666
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,5,main]: {}
> java.lang.RuntimeException:
> org.apache.cassandra.index.IndexNotAvailableException: The secondary index
> 'idx_ma_transaction_id' is not yet available
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2601)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_161]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
> Caused by: org.apache.cassandra.index.IndexNotAvailableException: The
> secondary index 'idx_ma_transaction_id' is not yet available
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:416)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1887)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2597)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> ... 5 common frames omitted
>
> Regards,
> Pradip
>
--
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-15163) Untangle RepairMessage sub-hierarchy of messages, use new messaging (more) correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15163:
--
Test and Documentation Plan: N/A
Status: Patch Available (was: Open)
> Untangle RepairMessage sub-hierarchy of messages, use new messaging (more)
> correctly
>
>
> Key: CASSANDRA-15163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15163
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> There is currently a nested sub-hierarchy of messages used by repair - in
> {{RepairMessage}} - all sharing one verb, all sharing one deserialiser, all
> sharing one verb handler. The first two can and should be addressed, and it’s
> mostly a mechanical task to do so. The last one should be tackled separately,
> when we get to refactor repair some day (and it could definitely use some
> love).
> The proposed patch follows-up the work done in CASSANDRA-15066 and makes
> repair use the new messaging service in a more correct way, making verbs and
> deserialization more explicit. It wasn't included into the original commit so
> that to not make the single commit larger that it needed to be.
--
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-15163) Untangle RepairMessage sub-hierarchy of messages, use new messaging (more) correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15163:
--
Complexity: Low Hanging Fruit
Assignee: Aleksey Yeschenko
Change Category: Semantic
Reviewers: Blake Eggleston
Status: Open (was: Triage Needed)
> Untangle RepairMessage sub-hierarchy of messages, use new messaging (more)
> correctly
>
>
> Key: CASSANDRA-15163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15163
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
>
> There is currently a nested sub-hierarchy of messages used by repair - in
> {{RepairMessage}} - all sharing one verb, all sharing one deserialiser, all
> sharing one verb handler. The first two can and should be addressed, and it’s
> mostly a mechanical task to do so. The last one should be tackled separately,
> when we get to refactor repair some day (and it could definitely use some
> love).
> The proposed patch follows-up the work done in CASSANDRA-15066 and makes
> repair use the new messaging service in a more correct way, making verbs and
> deserialization more explicit. It wasn't included into the original commit so
> that to not make the single commit larger that it needed to be.
--
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-15163) Untangle RepairMessage sub-hierarchy of messages, use new messaging (more) correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15163:
--
Fix Version/s: 4.0
> Untangle RepairMessage sub-hierarchy of messages, use new messaging (more)
> correctly
>
>
> Key: CASSANDRA-15163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15163
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.0
>
>
> There is currently a nested sub-hierarchy of messages used by repair - in
> {{RepairMessage}} - all sharing one verb, all sharing one deserialiser, all
> sharing one verb handler. The first two can and should be addressed, and it’s
> mostly a mechanical task to do so. The last one should be tackled separately,
> when we get to refactor repair some day (and it could definitely use some
> love).
> The proposed patch follows-up the work done in CASSANDRA-15066 and makes
> repair use the new messaging service in a more correct way, making verbs and
> deserialization more explicit. It wasn't included into the original commit so
> that to not make the single commit larger that it needed to be.
--
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-15163) Untangle RepairMessage sub-hierarchy of messages, use new messaging (more) correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864427#comment-16864427
]
Aleksey Yeschenko commented on CASSANDRA-15163:
---
Branch [here|https://github.com/iamaleksey/cassandra/commits/15163-4.0], CI
currently running
[here|https://circleci.com/workflow-run/974762ef-c520-4c80-8fbf-f1e0c019c85e].
> Untangle RepairMessage sub-hierarchy of messages, use new messaging (more)
> correctly
>
>
> Key: CASSANDRA-15163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15163
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Aleksey Yeschenko
>Priority: Normal
>
> There is currently a nested sub-hierarchy of messages used by repair - in
> {{RepairMessage}} - all sharing one verb, all sharing one deserialiser, all
> sharing one verb handler. The first two can and should be addressed, and it’s
> mostly a mechanical task to do so. The last one should be tackled separately,
> when we get to refactor repair some day (and it could definitely use some
> love).
> The proposed patch follows-up the work done in CASSANDRA-15066 and makes
> repair use the new messaging service in a more correct way, making verbs and
> deserialization more explicit. It wasn't included into the original commit so
> that to not make the single commit larger that it needed to be.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15163) Untangle RepairMessage sub-hierarchy of messages, use new messaging (more) correctly
Aleksey Yeschenko created CASSANDRA-15163:
-
Summary: Untangle RepairMessage sub-hierarchy of messages, use new
messaging (more) correctly
Key: CASSANDRA-15163
URL: https://issues.apache.org/jira/browse/CASSANDRA-15163
Project: Cassandra
Issue Type: Improvement
Components: Messaging/Internode
Reporter: Aleksey Yeschenko
There is currently a nested sub-hierarchy of messages used by repair - in
{{RepairMessage}} - all sharing one verb, all sharing one deserialiser, all
sharing one verb handler. The first two can and should be addressed, and it’s
mostly a mechanical task to do so. The last one should be tackled separately,
when we get to refactor repair some day (and it could definitely use some love).
The proposed patch follows-up the work done in CASSANDRA-15066 and makes repair
use the new messaging service in a more correct way, making verbs and
deserialization more explicit. It wasn't included into the original commit so
that to not make the single commit larger that it needed to be.
--
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
svn commit: r1861363 - in /cassandra/site: publish/ publish/doc/4.0/ publish/doc/4.0/architecture/ publish/doc/4.0/configuration/ publish/doc/4.0/cql/ publish/doc/4.0/development/ publish/doc/4.0/faq/
Author: mshuler
Date: Fri Jun 14 19:47:12 2019
New Revision: 1861363
URL: http://svn.apache.org/viewvc?rev=1861363&view=rev
Log:
Latest docs build for site.
This build was roughly:
docker-compose build cassandra-website
docker-compose run cassandra-website
# lots of svn status & diff throughout
sudo chown -R $USER: . # docker build writes everything as root
svn revert --recursive publish/blog/
rm -r publish/blog/2018/08/06 # no blogs were harmed in this commit
svn revert --recursive publish/doc/cql3
rm -r publish/doc/3.11.5
rm -r src/doc/3.11.5
rm -r src/.sass-cache
rm -r src/doc/4.0/_downloads/54214fb4f99d59730d4cda283a1e9a75/
rm -r src/doc/4.0/_downloads/87a3a4aa5557ff2196758c8fe2aecc51/
for f in `svn status |egrep '^!' |awk '{print $2}'`; do svn rm $f; done
svn commit
83k line diff. Sorry for that.
[This commit notification would consist of 75 parts,
which exceeds the limit of 50 ones, so it was shortened to the summary.]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15149) Change the text and link for low hanging fruit tickets to include the LHF ticket complexity
[ https://issues.apache.org/jira/browse/CASSANDRA-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864376#comment-16864376 ] Jeremy Hanna commented on CASSANDRA-15149: -- As a note, I bulk changed all unresolved tickets with the lhf label to have the Low Hanging Fruit complexity. That makes it so we can just use the Low Hanging Fruit complexity in the query going forward. So that's what I did in the link change in the docs. > Change the text and link for low hanging fruit tickets to include the LHF > ticket complexity > --- > > Key: CASSANDRA-15149 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15149 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Jeremy Hanna >Assignee: Jeremy Hanna >Priority: Normal > Fix For: 4.0 > > Attachments: CASSANDRA-15149.txt > > > Right now in the docs for how to contribute, it points to the lhf (low > hanging fruit) label which is how things were marked before the Jira flow > evolution. We should note the complexity field in there and include both the > label and the complexity field in the associated link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15162) IndexNotAvailableException: The secondary index 'idx_ma_transaction_id' is not yet available
Pradip Kumar created CASSANDRA-15162:
Summary: IndexNotAvailableException: The secondary index
'idx_ma_transaction_id' is not yet available
Key: CASSANDRA-15162
URL: https://issues.apache.org/jira/browse/CASSANDRA-15162
Project: Cassandra
Issue Type: Improvement
Components: Cluster/Schema
Reporter: Pradip Kumar
Hi,
I created an index on the table "moneyid_allocation" as below..
*CREATE INDEX idx_ma_transaction_id ON moneymarking.moneyid_allocation
(transaction_id);*
But when I am selecting the data by using the indexed column the got error in
the system.log, Please suggest to resolve the issue
There are around 10 million records in the table.
*select query:-*
select * from moneyid_allocation where transaction_id='11' limit 1
ALLOW FILTERING;
*Error in system.log:-*
WARN [ReadStage-4] 2019-06-14 23:28:56,666
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-4,5,main]: {}
java.lang.RuntimeException:
org.apache.cassandra.index.IndexNotAvailableException: The secondary index
'idx_ma_transaction_id' is not yet available
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2601)
~[apache-cassandra-3.11.3.jar:3.11.3]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_161]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.3.jar:3.11.3]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.3.jar:3.11.3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
[apache-cassandra-3.11.3.jar:3.11.3]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
Caused by: org.apache.cassandra.index.IndexNotAvailableException: The secondary
index 'idx_ma_transaction_id' is not yet available
at
org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:416)
~[apache-cassandra-3.11.3.jar:3.11.3]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1887)
~[apache-cassandra-3.11.3.jar:3.11.3]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2597)
~[apache-cassandra-3.11.3.jar:3.11.3]
... 5 common frames omitted
Regards,
Pradip
--
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-15157) Missing commands in nodetool help
[
https://issues.apache.org/jira/browse/CASSANDRA-15157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864157#comment-16864157
]
Romain Hardouin commented on CASSANDRA-15157:
-
{{cfXXX}} commands are deprecated from a long time ago and {{tableXXX}}
commands should be used instead.
You will notice that {{tablestats}} or {{tablehistograms}} are part of the
"nodetool help" output. Maybe your question is how to list aliases? You can't
unless if look at sources e.g.
[https://github.com/apache/cassandra/blob/033b30f869ea8a3171c22cbb3c5c517ce2a0fd59/src/java/org/apache/cassandra/tools/nodetool/CfStats.java#L25]
A grep (well, rg) shows that only two commands are hidden:
{code:java}
▶ rg 'hidden = true'
src/java/org/apache/cassandra/tools/nodetool/CfStats.java
25:@Command(name = "cfstats", hidden = true, description = "Print statistics on
tables")
src/java/org/apache/cassandra/tools/nodetool/CfHistograms.java
25:@Command(name = "cfhistograms", hidden = true, description = "Print
statistic histograms for a given column family")
{code}
> Missing commands in nodetool help
> -
>
> Key: CASSANDRA-15157
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15157
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Yakir Gibraltar
>Priority: Normal
>
> Hi, how to gel *all* available commands of nodetool? like cfhistograms,
> cfstats, etc.
> "nodetool help" does not return all commands.
> for example:
> {code}
> [root@ctaz001 ~]# nodetool version
> ReleaseVersion: 3.11.4
> [root@ctaz001 ~]# nodetool help | grep cfh | wc -l
> 0
> [root@ctaz001 ~]# nodetool help
> usage: nodetool [(-p | --port )]
> [(-u | --username )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-h | --host )] []
> The most commonly used nodetool commands are:
> assassinate Forcefully remove a dead node without
> re-replicating any data. Use as a last resort if you cannot removenode
> bootstrapMonitor/manage node's bootstrap process
> cleanup Triggers the immediate cleanup of keys no
> longer belonging to a node. By default, clean all keyspaces
> clearsnapshotRemove the snapshot with the given name from
> the given keyspaces. If no snapshotName is specified we will remove all
> snapshots
> compact Force a (major) compaction on one or more
> tables or user-defined compaction on given SSTables
> compactionhistoryPrint history of compaction
> compactionstats Print statistics on compactions
> decommission Decommission the *node I am connecting to*
> describecluster Print the name, snitch, partitioner and
> schema version of a cluster
> describering Shows the token ranges info of a given
> keyspace
> disableautocompactionDisable autocompaction for the given
> keyspace and table
> disablebackupDisable incremental backup
> disablebinaryDisable native transport (binary protocol)
> disablegossipDisable gossip (effectively marking the node
> down)
> disablehandoff Disable storing hinted handoffs
> disablehintsfordcDisable hints for a data center
> disablethriftDisable thrift server
> drainDrain the node (stop accepting writes and
> flush all tables)
> enableautocompaction Enable autocompaction for the given keyspace
> and table
> enablebackup Enable incremental backup
> enablebinary Reenable native transport (binary protocol)
> enablegossip Reenable gossip
> enablehandoffReenable future hints storing on the current
> node
> enablehintsfordc Enable hints for a data center that was
> previsouly disabled
> enablethrift Reenable thrift server
> failuredetector Shows the failure detector information for
> the cluster
> flushFlush one or more tables
> garbagecollect Remove deleted data from one or more tables
> gcstats Print GC Statistics
> getcompactionthreshold Print min and max compaction thresholds for
> a given table
> getcompactionthroughput Print the MB/s throughput cap for compaction
> in the system
> getconcurrentcompactors Get the number of concurrent compactors in
> the system.
> getendpoints Print the end points that owns the key
> getinterdcstreamthroughput Print the Mb/s throughput cap for
> inter-datacenter streaming in the
[jira] [Commented] (CASSANDRA-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864119#comment-16864119 ] Pedro Gordo commented on CASSANDRA-15161: - [~arganzheng] the emails are in that page. Just click on the link for the mailing list you want (Users or Developers). > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. > Thanks in advance. -- 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-12005) Out of memory error in MessagingService
[ https://issues.apache.org/jira/browse/CASSANDRA-12005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864029#comment-16864029 ] Chakravarthi Manepalli commented on CASSANDRA-12005: I have faced a similar issue, heap overflows after 15-30 min time from the node restart. Setup environment - single node running in localhost with 64GB RAM and 8GB HEAP memory nodetool info: ID : 35c11cc6-f881-4685-b211-654c4a21bf59 Gossip active : true Thrift active : false Native Transport active: true Load : 4.57 MiB Generation No : 1560507197 Uptime (seconds) : 250 Heap Memory (MB) : 301.67 / 8112.00 Off Heap Memory (MB) : 0.01 Data Center : datacenter1 Rack : rack1 Exceptions : 0 Key Cache : entries 128, size 16.5 KiB, capacity 100 MiB, 375 hits, 510 requests, 0.735 recent hit rate, 14400 save period in seconds Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds Chunk Cache : entries 19, size 1.19 MiB, capacity 480 MiB, 495 misses, 1126 requests, 0.560 recent hit rate, 48.843 microseconds miss latency Percent Repaired : 100.0% Token : (invoke with -T/--tokens to see all 256 tokens) The node shows running in service status but unable to take cqlsh or access nodetool. ERROR [Native-Transport-Requests-1] 2019-06-14 14:41:35,747 JVMStabilityInspector.java:74 - OutOfMemory error letting the JVM handle the error: java.lang.OutOfMemoryError: Java heap space at org.apache.cassandra.db.Clustering.make(Clustering.java:81) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.db.CBuilder$ArrayBackedBuilder.buildWith(CBuilder.java:210) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.db.MultiCBuilder$MultiClusteringBuilder.build(MultiCBuilder.java:416) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:113) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.statements.SelectStatement.getRequestedRows(SelectStatement.java:765) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.statements.SelectStatement.makeClusteringIndexFilter(SelectStatement.java:628) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:519) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:306) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:282) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:117) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:255) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:240) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116) ~[apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517) [apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410) [apache-cassandra-3.11.3.jar:3.11.3] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.44.Final.jar:4.0.44.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357) [netty-all-4.0.44.Final.jar:4.0.44.Final] at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35) [netty-all-4.0.44.Final.jar:4.0.44.Final] at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348) [netty-all-4.0.44.Final.jar:4.0.44.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_212] at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162) [apache-cassandra-3.11.3.jar:3.11.3] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) [apache-cassandra-3.11.3.jar:3.11.3] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_212] WARN [epollEventLoopGroup-2-5] 2019-06-14 14:41:35,748 Slf4J
[jira] [Commented] (CASSANDRA-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864027#comment-16864027 ] arganzheng commented on CASSANDRA-15161: Please leave the email address cause I can not find it in the website [http://cassandra.apache.org/community/#mailing] > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. > Thanks in advance. -- 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-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-15161: Resolution: Invalid Status: Resolved (was: Triage Needed) > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. > Thanks in advance. -- 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-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864020#comment-16864020 ] Joshua McKenzie commented on CASSANDRA-15161: - Please take questions like this to the user mailing list. This Jira is for tracking development of the project. > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. > Thanks in advance. -- 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-15160) Add flag to ignore unreplicated keyspaces during repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15160:
Test and Documentation Plan: 2 dtests added,
https://github.com/krummas/cassandra-dtest/commits/marcuse/15160
Status: Patch Available (was: Open)
> Add flag to ignore unreplicated keyspaces during repair
> ---
>
> Key: CASSANDRA-15160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15160
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> When a repair is triggered on a node in 'dc2' for a keyspace with replication
> factor {'dc1':3, 'dc2':0} we just ignore the repair in versions < 4. In 4.0
> we fail the repair to make sure the operator does not think the keyspace is
> fully repaired.
> There might be tooling that relies on the old behaviour though, so we should
> add a flag to ignore those unreplicated keyspaces
>
--
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-15160) Add flag to ignore unreplicated keyspaces during repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15160:
Complexity: Low Hanging Fruit
Change Category: Operability
Reviewers: Blake Eggleston
Status: Open (was: Triage Needed)
trunk patch: https://github.com/krummas/cassandra/commits/marcuse/15160
dtests: https://github.com/krummas/cassandra-dtest/commits/marcuse/15160
circleci: https://circleci.com/workflow-run/4f0960b3-649d-4a35-a1bc-0cbb4b40b045
> Add flag to ignore unreplicated keyspaces during repair
> ---
>
> Key: CASSANDRA-15160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15160
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> When a repair is triggered on a node in 'dc2' for a keyspace with replication
> factor {'dc1':3, 'dc2':0} we just ignore the repair in versions < 4. In 4.0
> we fail the repair to make sure the operator does not think the keyspace is
> fully repaired.
> There might be tooling that relies on the old behaviour though, so we should
> add a flag to ignore those unreplicated keyspaces
>
--
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-15160) Add flag to ignore unreplicated keyspaces during repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15160:
Description:
When a repair is triggered on a node in 'dc2' for a keyspace with replication
factor {'dc1':3, 'dc2':0} we just ignore the repair in versions < 4. In 4.0 we
fail the repair to make sure the operator does not think the keyspace is fully
repaired.
There might be tooling that relies on the old behaviour though, so we should
add a flag to ignore those unreplicated keyspaces
was:
When a repair is triggered on a node in 'dc2' for a keyspace with replication
factor {{{'dc1':3, 'dc2':0}}} we just ignore the repair in versions < 4. In 4.0
we fail the repair to make sure the operator does not think the keyspace is
fully repaired.
There might be tooling that relies on the old behaviour though, so we should
add a flag to ignore those unreplicated keyspaces
> Add flag to ignore unreplicated keyspaces during repair
> ---
>
> Key: CASSANDRA-15160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15160
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> When a repair is triggered on a node in 'dc2' for a keyspace with replication
> factor {'dc1':3, 'dc2':0} we just ignore the repair in versions < 4. In 4.0
> we fail the repair to make sure the operator does not think the keyspace is
> fully repaired.
> There might be tooling that relies on the old behaviour though, so we should
> add a flag to ignore those unreplicated keyspaces
>
--
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-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] arganzheng updated CASSANDRA-15161: --- Description: Cassandra claims to be a schema-free NoSQL, however I can not insert record without define every column before I can insert it. Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. Thanks in advance. was: Cassandra claims to be a schema-free NoSQL, however I can not insert record without define every column before I can insert it. Someone please tell me I was wrong, or Cassandra is acturlly NOT schema-less. Thanks in advance. > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is actually NOT schema-less. > Thanks in advance. -- 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-15161) Cassandra is not Schema-free?!
[ https://issues.apache.org/jira/browse/CASSANDRA-15161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] arganzheng updated CASSANDRA-15161: --- Description: Cassandra claims to be a schema-free NoSQL, however I can not insert record without define every column before I can insert it. Someone please tell me I was wrong, or Cassandra is acturlly NOT schema-less. Thanks in advance. was: Cassandra claims to be a schema-free NoSQL, however I can not insert record without define every column before I can insert it. Someone please tell me I WAS WRONG, or Cassandra is acturely NOT schema-less. Thanks in advance. > Cassandra is not Schema-free?! > -- > > Key: CASSANDRA-15161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: arganzheng >Priority: Normal > > Cassandra claims to be a schema-free NoSQL, however I can not insert record > without define every column before I can insert it. > Someone please tell me I was wrong, or Cassandra is acturlly NOT schema-less. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15161) Cassandra is not Schema-free?!
arganzheng created CASSANDRA-15161: -- Summary: Cassandra is not Schema-free?! Key: CASSANDRA-15161 URL: https://issues.apache.org/jira/browse/CASSANDRA-15161 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: arganzheng Cassandra claims to be a schema-free NoSQL, however I can not insert record without define every column before I can insert it. Someone please tell me I WAS WRONG, or Cassandra is acturely NOT schema-less. Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15160) Add flag to ignore unreplicated keyspaces during repair
Marcus Eriksson created CASSANDRA-15160:
---
Summary: Add flag to ignore unreplicated keyspaces during repair
Key: CASSANDRA-15160
URL: https://issues.apache.org/jira/browse/CASSANDRA-15160
Project: Cassandra
Issue Type: Improvement
Components: Consistency/Repair
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
When a repair is triggered on a node in 'dc2' for a keyspace with replication
factor {{{'dc1':3, 'dc2':0}}} we just ignore the repair in versions < 4. In 4.0
we fail the repair to make sure the operator does not think the keyspace is
fully repaired.
There might be tooling that relies on the old behaviour though, so we should
add a flag to ignore those unreplicated keyspaces
--
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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863768#comment-16863768 ] Dinesh Joshi edited comment on CASSANDRA-10190 at 6/14/19 7:19 AM: --- Hi [~ptbannister], thank you for making the changes. The latest set of changes look good. [I ran the dtests|https://circleci.com/workflow-run/9ce3ae71-70d4-4fd7-b590-1449323408ff]. There are some cqlsh related failures in the vnodes case. Could you please take a look? Additionally, as part of this change, it would be desirable to run cqlsh tests with Python 2.7 as well as Python 3. I think it would be trivial to do it if we can override the Python interpreter's path by providing it as a parameter. WDYT? was (Author: djoshi3): Hi [~ptbannister], thank you for making the changes. The latest set of changes look good. I ran the dtests. There are some cqlsh related failures in the vnodes case. Could you please take a look? Additionally, as part of this change, I think it would be desirable to run cqlsh tests with Python 2.7 as well as Python 3. I think it would be trivial to do it if we can override the Python interpreter's path by providing it as a parameter. WDYT? > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863768#comment-16863768 ] Dinesh Joshi commented on CASSANDRA-10190: -- Hi [~ptbannister], thank you for making the changes. The latest set of changes look good. I ran the dtests. There are some cqlsh related failures in the vnodes case. Could you please take a look? Additionally, as part of this change, I think it would be desirable to run cqlsh tests with Python 2.7 as well as Python 3. I think it would be trivial to do it if we can override the Python interpreter's path by providing it as a parameter. WDYT? > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
