Golang + Cassandra + Text Search

[Ridley Submission]

Hi,

Quick question, I am wondering if anyone here who works with Go has
specific recommendations for as simple framework to add text search on top
of cassandra?

(Apologies if this is off topic—I am not quite sure what forum in the
cassandra community would be best for this type of question)

Thanks,
Riley

QueryProcessor.java:160 - prepared statement recreation error

[Ridley Submission]

Just did a restart on a node I'm upgrading from 3.11.0 to 3.11.1 and I am a
delayed startup due to a large sequence of these type of messages::

WARN  [main] 2017-10-16 12:53:16,040 QueryProcessor.java:160 - prepared
statement recreation error: select link, processed from to_editor where
timeblock in
('2017092300','2017092218','2017092212','2017092206','2017092200','2017092118','2017092112','2017092106')
org.apache.cassandra.exceptions.InvalidRequestException:
unconfigured table to_editor
at
org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily(ThriftValidation.java:115)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:958)
~[apache-cassandra-3.11.1.jar:3.11.1]

Is it correct to take the advise on stack overflow to simply wipe out

truncate system.prepared_statements;

https://stackoverflow.com/questions/44973340/why-am-i-getting-cassandra-prepared-statement-recreation-error-on-startup-from-d

Thanks!
Ridley

Re: How to interpret uninterpreted `nodetool compact` java stack trace in 3.11.0

[Ridley Submission]

Ok thanks for your reply.

I do believe this one is already in JIRA:

https://issues.apache.org/jira/browse/CASSANDRA-13897?jql=text%20~%20%22nodetool%20flush%20compact%22

Regards,
Ridley

NB: The debug.log provides only minimal extra information above what is in
that JIRA ticket. The name of the table this error occurs on changes
occasionally. I've not yet come across any practical impact in the running
of our system. I don't know if it is strange, but the only thing that seems
strange to me is that the commit logs on a node appear to grow to be 20
times the size of the actual data sstables (even after compaction):

DEBUG [PerDiskMemtableFlushWriter_0:967] 2017-10-09 14:31:44,659
Memtable.java:490 - Completed flushing
/home/cass/apache-cassandra-3.11.0/data/data/newsreader/article-82769690885f11e7ad7a7dd51e316d41/mc-307-big-Data.db
(184.877KiB) for commitlog position
CommitLogPosition(segmentId=1506151484359, position=28204113)
ERROR [MemtablePostFlush:540] 2017-10-09 14:31:44,688
CassandraDaemon.java:228 - Exception in thread
Thread[MemtablePostFlush:540,5,RMI Runtime]
java.lang.AssertionError: null
at
org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
~[apache-cassandra-3.11.0.jar:3.11.0]
at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.access$600(BigTableWriter.java:53)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter$TransactionalProxy.doPrepare(BigTableWriter.java:374)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.sstable.format.SSTableWriter.prepareToCommit(SSTableWriter.java:281)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.prepareToCommit(SimpleSSTableMultiWriter.java:101)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1153)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1086)
~[apache-cassandra-3.11.0.jar:3.11.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_144]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_144]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
[apache-cassandra-3.11.0.jar:3.11.0]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144]
ERROR [Reference-Reaper:1] 2017-10-09 14:31:45,247 Ref.java:224 - LEAK
DETECTED: a reference
(org.apache.cassandra.utils.concurrent.Ref$State@eefaa4) to class
org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@20886337
:[Memory@[0..30), Memory@[0..1e0)] was not released before the reference
was garbage collected
ERROR [Reference-Reaper:1] 2017-10-09 14:31:46,725 Ref.java:224 - LEAK
DETECTED: a reference
(org.apache.cassandra.utils.concurrent.Ref$State@1082ad6) to class
org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@19319642
:[Memory@[0..90), Memory@[0..2d0)] was not released before the reference
was garbage collected


On Mon, Oct 9, 2017 at 2:22 PM, Jeff Jirsa  wrote:

> Likely failed but you’d need to check the full logs to be positive
>
> Assertion errors typically should be reported on the JIRA - you’ve
> encountered a situation the developer didn’t think was possible so it’s
> aborted, but we need to know that you encountered it so we can fix it
>
> Please open the jira here with as much info as you can safely provide
> (anonymize logs as needed):
> https://issues.apache.org/jira/projects/CASSANDRA/summary
>
>
> --
> Jeff Jirsa
>
>
> On Oct 8, 2017, at 8:19 PM, Ridley Submissions <
> ridley.submission2...@gmail.com> wrote:
>
> Hi Everyone,
>
> I wonder how do we interpret this error message? Does it mean that the
> compaction failed?  Is this an error I should be concerned about?
>
> Thanks,
> Ridley
>
>
> cassandra@server:$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.cache.ChunkCache$CachingRebufferer.<
> init>(ChunkCache.java:222)
> at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
> at 

How to interpret uninterpreted `nodetool compact` java stack trace in 3.11.0

[Ridley Submission]

Hi Everyone,

I wonder how do we interpret this error message? Does it mean that the
compaction failed?  Is this an error I should be concerned about?

Thanks,
Ridley


cassandra@server:$ nodetool compact
error: null
-- StackTrace --
java.lang.AssertionError
at
org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
at
org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)