Re: Is the updating compaction strategy from 'sized tiered' to 'leveled' automatic or need to be done manually?

[Yatong Zhang]

I tried to run 'nodetool compact' (or with keyspace and cfname), seemed not
woking. The command hung there and nothing happened. But I noticed that
there was about more 3+ pending tasks when using 'nodetool
compactionsats'


On Tue, May 6, 2014 at 1:45 AM, Robert Coli  wrote:

> On Mon, May 5, 2014 at 12:24 AM, Daniel Chia  wrote:
>
>> If you want to trigger a conversion to LCS of the on-disk sstables, doing
>> "nodetool compact " should achieve what you want.
>>
>
> For more detail and a caveat :
>
> https://issues.apache.org/jira/browse/CASSANDRA-6092
> "
> The workaround to call "nodetool compact" only works when there is at
> least some activity, causing there to be more than 1 sstable. I've just
> tested with a cluster that was not receiving any reads nor writes. In that
> case calling "nodetool compact" does not do anything ...
> "
>
> =Rob
>
>

Re: error in cassandra log file under stress

[Robert Coli]

On Mon, May 5, 2014 at 2:03 PM, Mohica Jasha  wrote:

> Our prod deployment:
>
> C* 2.0.5, DC1:3, DC2:3
>

Not directly related to your bug report, which I would file an Apache JIRA
regarding, but...

https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/

=Rob

Re: error in cassandra log file under stress

[Mohica Jasha]

Most likely it is the following query:

DELETE from conditional_update_lock where resource_id = '${myresourceid}' IF
lock_id = ${myuuid};

We are using datastax 2.0.1 and the datastax threw a ReadtimeoutException





On Mon, May 5, 2014 at 5:03 PM, Mohica Jasha  wrote:

> forgot to say which Cassandra version we are using.
>
> Our prod deployment:
>
> C* 2.0.5, DC1:3, DC2:3
>
>
>
>
> On Mon, May 5, 2014 at 5:01 PM, Mohica Jasha wrote:
>
>> one query in our prod system under heavy load failed.
>> I cant tell which query it was. But I don't think we were using an
>> invalid consistency level since our configuration work all the time except
>> when it goes under heavy load.
>> If I can reproduce this I will pass more information.
>>
>> I wonder if this is due to a race condition in Paxos implementation.
>> I found the following in the cassandra's log file:
>>
>>
>> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794
 QueryMessage.java (line 131) Unexpected error during query
>>>
>>> java.lang.UnsupportedOperationException: Invalid consistency level:
 LOCAL_SERIAL
>>>
>>> at
 org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
>>>
>>> at
 org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
>>>
>>> at
 org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
>>>
>>> at
 org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
>>>
>>> at
 org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
>>>
>>> at
 org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>>>
>>> at
 org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
>>>
>>> at
 org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>>>
>>> at
 org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
>>>
>>> at
 org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>>>
>>> at
 org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>>>
>>> at
 org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
>>>
>>> at
 org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
>>>
>>> at
 org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
>>>
>>> at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>
>>> at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>
>>> at java.lang.Thread.run(Thread.java:744)
>>>
>>> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794
 ErrorMessage.java (line 222) Unexpected exception during request
>>>
>>> java.lang.UnsupportedOperationException: Invalid consistency level:
 LOCAL_SERIAL
>>>
>>> at
 org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
>>>
>>> at
 org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
>>>
>>> at
 org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
>>>
>>> at
 org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
>>>
>>> at
 org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
>>>
>>> at
 org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>>>
>>> at
 org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
>>>
>>> at
 org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>>>
>>> at
 org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
>>>
>>> at
 org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>>>
>>> at
 org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>>>
>>> at
 org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
>>>
>>> at
 org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
>>>
>>> at
 org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
>>>
>>> at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>
>>> at
 java.util.concurrent.ThreadPoo

Re: error in cassandra log file under stress

[Mohica Jasha]

forgot to say which Cassandra version we are using.

Our prod deployment:

C* 2.0.5, DC1:3, DC2:3




On Mon, May 5, 2014 at 5:01 PM, Mohica Jasha  wrote:

> one query in our prod system under heavy load failed.
> I cant tell which query it was. But I don't think we were using an invalid
> consistency level since our configuration work all the time except when it
> goes under heavy load.
> If I can reproduce this I will pass more information.
>
> I wonder if this is due to a race condition in Paxos implementation.
> I found the following in the cassandra's log file:
>
>
> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794
>>> QueryMessage.java (line 131) Unexpected error during query
>>
>> java.lang.UnsupportedOperationException: Invalid consistency level:
>>> LOCAL_SERIAL
>>
>> at
>>> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
>>
>> at
>>> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
>>
>> at
>>> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
>>
>> at
>>> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
>>
>> at
>>> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
>>
>> at
>>> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>>
>> at
>>> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
>>
>> at
>>> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>>
>> at
>>> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
>>
>> at
>>> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>>
>> at
>>> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>>
>> at
>>> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
>>
>> at
>>> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
>>
>> at
>>> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
>>
>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>
>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>
>> at java.lang.Thread.run(Thread.java:744)
>>
>> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794
>>> ErrorMessage.java (line 222) Unexpected exception during request
>>
>> java.lang.UnsupportedOperationException: Invalid consistency level:
>>> LOCAL_SERIAL
>>
>> at
>>> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
>>
>> at
>>> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
>>
>> at
>>> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
>>
>> at
>>> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
>>
>> at
>>> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
>>
>> at
>>> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>>
>> at
>>> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
>>
>> at
>>> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>>
>> at
>>> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
>>
>> at
>>> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>>
>> at
>>> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>>
>> at
>>> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
>>
>> at
>>> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
>>
>> at
>>> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
>>
>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>
>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>
>> at java.lang.Thread.run(Thread.java:744)
>>
>>

error in cassandra log file under stress

[Mohica Jasha]

one query in our prod system under heavy load failed.
I cant tell which query it was. But I don't think we were using an invalid
consistency level since our configuration work all the time except when it
goes under heavy load.
If I can reproduce this I will pass more information.

I wonder if this is due to a race condition in Paxos implementation.
I found the following in the cassandra's log file:


ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794
>> QueryMessage.java (line 131) Unexpected error during query
>
> java.lang.UnsupportedOperationException: Invalid consistency level:
>> LOCAL_SERIAL
>
> at
>> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
>
> at
>> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
>
> at
>> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
>
> at
>> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
>
> at
>> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
>
> at
>> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>
> at
>> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
>
> at
>> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>
> at
>> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
>
> at
>> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>
> at
>> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>
> at
>> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
>
> at
>> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
>
> at
>> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
>
> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:744)
>
> ERROR [Native-Transport-Requests:457009] 2014-05-02 13:49:09,794
>> ErrorMessage.java (line 222) Unexpected exception during request
>
> java.lang.UnsupportedOperationException: Invalid consistency level:
>> LOCAL_SERIAL
>
> at
>> org.apache.cassandra.db.ConsistencyLevel.blockFor(ConsistencyLevel.java:137)
>
> at
>> org.apache.cassandra.service.StorageProxy.beginAndRepairPaxos(StorageProxy.java:416)
>
> at
>> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:228)
>
> at
>> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:423)
>
> at
>> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:380)
>
> at
>> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:188)
>
> at
>> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222)
>
> at
>> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>
> at
>> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:304)
>
> at
>> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>
> at
>> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>
> at
>> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
>
> at
>> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
>
> at
>> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
>
> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:744)
>
>

Re: cassandra snapshots

[Batranut Bogdan]

Hello Robert,

Neither of those actions were taken on that cf as far as I know. In that cf we 
only insert historical data. No deletes no drops / truncates.

Thanks
On Monday, May 5, 2014 10:50 PM, Robert Coli  wrote:
 
On Mon, May 5, 2014 at 12:48 PM, Batranut Bogdan  wrote:

I have a big col family and I see that cassandra is taking snapshots for it. I 
do not have incremental enabled. What are the triggers that start the process 
of taking a snapshot? Is is automatic ?

It's automatic if you DROP or TRUNCATE a columnfamily or keyspace.

=Rob

Re: cassandra snapshots

[Robert Coli]

On Mon, May 5, 2014 at 12:48 PM, Batranut Bogdan  wrote:

> I have a big col family and I see that cassandra is taking snapshots for
> it. I do not have incremental enabled. What are the triggers that start the
> process of taking a snapshot? Is is automatic ?
>

It's automatic if you DROP or TRUNCATE a columnfamily or keyspace.

=Rob

cassandra snapshots

[Batranut Bogdan]

Hello all

I have a big col family and I see that cassandra is taking snapshots for it. I 
do not have incremental enabled. What are the triggers that start the process 
of taking a snapshot? Is is automatic ?

Thanks

Re: Cassandra 2.0.7 always failes due to 'too may open files' error

[Bryan Talbot]

Running

#> cat /proc/$(cat /var/run/cassandra.pid)/limits

as root or your cassandra user will tell you what limits it's actually
running with.




On Sun, May 4, 2014 at 10:12 PM, Yatong Zhang  wrote:

> I am running 'repair' when the error occurred. And just a few days before
> I changed the compaction strategy to 'leveled'. don know if this helps
>
>
> On Mon, May 5, 2014 at 1:10 PM, Yatong Zhang  wrote:
>
>> Cassandra is running as root
>>
>> [root@storage5 ~]# ps aux | grep java
>>> root  1893 42.0 24.0 7630664 3904000 ? Sl   10:43  60:01 java
>>> -ea -javaagent:/mydb/cassandra/bin/../lib/jamm-0.2.5.jar
>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>> -XX:ThreadPriorityPolicy=42 -Xms3959M -Xmx3959M -Xmn400M
>>> -XX:+HeapDumpOnOutOfMemoryError -Xss256k -XX:StringTableSize=103
>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
>>> -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
>>> -XX:+UseTLAB -XX:+UseCondCardMark -Djava.net.preferIPv4Stack=true
>>> -Dcom.sun.management.jmxremote.port=7199
>>> -Dcom.sun.management.jmxremote.ssl=false
>>> -Dcom.sun.management.jmxremote.authenticate=false
>>> -Dlog4j.configuration=log4j-server.properties
>>> -Dlog4j.defaultInitOverride=true -Dcassandra-pidfile=/var/run/cassandra.pid
>>> -cp
>>> /mydb/cassandra/bin/../conf:/mydb/cassandra/bin/../build/classes/main:/mydb/cassandra/bin/../build/classes/thrift:/mydb/cassandra/bin/../lib/antlr-3.2.jar:/mydb/cassandra/bin/../lib/apache-cassandra-2.0.7.jar:/mydb/cassandra/bin/../lib/apache-cassandra-clientutil-2.0.7.jar:/mydb/cassandra/bin/../lib/apache-cassandra-thrift-2.0.7.jar:/mydb/cassandra/bin/../lib/commons-cli-1.1.jar:/mydb/cassandra/bin/../lib/commons-codec-1.2.jar:/mydb/cassandra/bin/../lib/commons-lang3-3.1.jar:/mydb/cassandra/bin/../lib/compress-lzf-0.8.4.jar:/mydb/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.3.jar:/mydb/cassandra/bin/../lib/disruptor-3.0.1.jar:/mydb/cassandra/bin/../lib/guava-15.0.jar:/mydb/cassandra/bin/../lib/high-scale-lib-1.1.2.jar:/mydb/cassandra/bin/../lib/jackson-core-asl-1.9.2.jar:/mydb/cassandra/bin/../lib/jackson-mapper-asl-1.9.2.jar:/mydb/cassandra/bin/../lib/jamm-0.2.5.jar:/mydb/cassandra/bin/../lib/jbcrypt-0.3m.jar:/mydb/cassandra/bin/../lib/jline-1.0.jar:/mydb/cassandra/bin/../lib/json-simple-1.1.jar:/mydb/cassandra/bin/../lib/libthrift-0.9.1.jar:/mydb/cassandra/bin/../lib/log4j-1.2.16.jar:/mydb/cassandra/bin/../lib/lz4-1.2.0.jar:/mydb/cassandra/bin/../lib/metrics-core-2.2.0.jar:/mydb/cassandra/bin/../lib/netty-3.6.6.Final.jar:/mydb/cassandra/bin/../lib/reporter-config-2.1.0.jar:/mydb/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/mydb/cassandra/bin/../lib/slf4j-api-1.7.2.jar:/mydb/cassandra/bin/../lib/slf4j-log4j12-1.7.2.jar:/mydb/cassandra/bin/../lib/snakeyaml-1.11.jar:/mydb/cassandra/bin/../lib/snappy-java-1.0.5.jar:/mydb/cassandra/bin/../lib/snaptree-0.1.jar:/mydb/cassandra/bin/../lib/super-csv-2.1.0.jar:/mydb/cassandra/bin/../lib/thrift-server-0.3.3.jar
>>> org.apache.cassandra.service.CassandraDaemon
>>>
>>
>>
>>
>> On Mon, May 5, 2014 at 1:02 PM, Philip Persad wrote:
>>
>>> Have you tried running "ulimit -a" as the Cassandra user instead of as
>>> root? It is possible that your configured a high file limit for root but
>>> not for the user running the Cassandra process.
>>>
>>>
>>> On Sun, May 4, 2014 at 6:07 PM, Yatong Zhang wrote:
>>>
 [root@storage5 ~]# lsof -n | grep java | wc -l
> 5103
> [root@storage5 ~]# lsof | wc -l
> 6567


 It's mentioned in previous mail:)


 On Mon, May 5, 2014 at 9:03 AM, nash  wrote:

> The lsof command or /proc can tell you how many open files it has. How
> many is it?
>
> --nash
>


>>>
>>
>

Re: Is there a way to stop cassandra compacting some large sstables?

[Robert Coli]

On Sun, May 4, 2014 at 10:26 PM, Yatong Zhang  wrote:

> 2. Is there a way to convert these old huge sstables into small 'leveled'
> ones? I tried 'sstablesplit' but always got an error with java EOF
> exception.
>

Could you be more specific about how you are attempting to use sstablesplit
and what error you are getting?

=Rob

Re: Is the updating compaction strategy from 'sized tiered' to 'leveled' automatic or need to be done manually?

[Robert Coli]

On Mon, May 5, 2014 at 12:24 AM, Daniel Chia  wrote:

> If you want to trigger a conversion to LCS of the on-disk sstables, doing
> "nodetool compact " should achieve what you want.
>

For more detail and a caveat :

https://issues.apache.org/jira/browse/CASSANDRA-6092
"
The workaround to call "nodetool compact" only works when there is at least
some activity, causing there to be more than 1 sstable. I've just tested
with a cluster that was not receiving any reads nor writes. In that case
calling "nodetool compact" does not do anything ...
"

=Rob

Avoiding email duplicates when registering users

[Ignacio Martin]

Hi,

I know this is a pretty common topic, but I haven't found any solution that
really satisfy me. The problem is well known: you have a table with user
information with a UUID as primary key, but you want to avoid email
duplicates when new users register.

The closest solution I've found is this:

https://www.mail-archive.com/user@cassandra.apache.org/msg19766.html

It achieves the goal of avoiding confirmed users account with the same
email, but I think that does not avoid malicious users to fill your user
table with pending registrations (if you don't confirm any). I know that
this is a minor thing, but anyway.

I have though of a solution and it would be great if you could confirm that
it is a good one. Assume you have a table with the user information with a
UUID as primary key, and an "index" table email_to_UUID with email as
primary key.

When a user registers, the server generates a UUID and performs an INSERT
... IF NOT EXISTS into the email_to_UUID table. Immediately after, perform
a SELECT from the same table and see if the read UUID is the same that the
one we just generated. If it is, we are allowed to INSERT the data in the
user table, knowing that no other will be doing it.

Does this sound right ? Is this the right way to have sort of UNIQUE
columns ?

Thanks in advance

[BETA RELEASE] Apache Cassandra 2.1.0-beta2 released

[Sylvain Lebresne]

The Cassandra team is pleased to announce the release of the 2nd beta for
the future Apache Cassandra 2.1.0.

Let first stress that this is beta software and as such is *not* ready for
production use.

The goal of this release is to give a preview of what will become Cassandra
2.1 and to get wider testing in preparation for the final release. This
beta is known to contain bugs but all help in testing this beta would be
greatly appreciated and will help make 2.1 a solid release. Please report
any
problem you may encounter[3,4] with this release and have a look at the
change
log[1] and release notes[2] to see where Cassandra 2.1 differs from the
previous series.

Apache Cassandra 2.1.0-beta2[5] is available as usual from the cassandra
website (http://cassandra.apache.org/download/) and a debian package is
available using the 21x branch (see
http://wiki.apache.org/cassandra/DebianPackaging).

Thank you for your help in testing and have fun with it.

[1]: http://goo.gl/iDbwjb (CHANGES.txt)
[2]: http://goo.gl/rGJJmK (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA
[4]: user@cassandra.apache.org
[5]:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/cassandra-2.1.0-beta2

Automatic tombstone removal issue (STCS)

[Paulo Ricardo Motta Gomes]

Hello,

After noticing that automatic tombstone removal (CASSANDRA-3442) was not
working in an append-only STCS CF with 40% of droppable tombstone ratio I
investigated why the compaction was not being triggered in the largest
SSTable with 16GB and about 70% droppable tombstone ratio.

When the code goes to check if the SSTable is candidate to be compacted
(AbstractCompactionStrategy.worthDroppingTombstones), it verifies if all
the others SSTables overlap with the current SSTable by checking if the
start and end tokens overlap. The problem is that all SSTables contain
pretty much the whole node token range, so all of them overlap nearly all
the time, so the automatic tombstone removal never happens. Is there any
case in STCS where all sstables token ranges DO NOT overlap?

I understand during the tombstone removal process it's necessary to verify
if the compacted row exists in any other SSTable, but I don't understand
why it's necessary to verify if the token ranges overlap to decide if a
tombstone compaction must be executed on a single SSTable with high
droppable tombstone ratio.

Any clarification would be kindly appreciated.

PS: Cassandra version: 1.2.16

-- 
*Paulo Motta*

Chaordic | *Platform*
*www.chaordic.com.br *
+55 48 3232.3200

RE: *Union* data type modeling in Cassandra

[Ngoc Minh VO]

Thanks for your prompt answer. It works great! (simple and efficient!)

Since I could not “bind” column name in prepared statement, I created 4 
separate ones for each data type.

It would be nice to have “INSERT INTO data_table(key, ?) VALUES (?, ?)” ☺

Regards,
Minh

From: doanduy...@gmail.com [mailto:doanduy...@gmail.com]
Sent: vendredi 2 mai 2014 12:29
To: user@cassandra.apache.org
Subject: Re: *Union* data type modeling in Cassandra

Hello Ngoc Minh

 I'd go with the first data model. To solve the null <-> tombstone issue, just 
do not insert them at runtime if value is null.

 If only numvalue double != null -> INSERT INTO data_table(key,numvalue) 
VALUES(...,...);
 If only numvalues list != null -> INSERT INTO 
data_table(key,numvalues) VALUES(...,...);
and so on ...

 It means that you'll need to somehow perform null check in your code at 
runtime but it's the price to pay to avoid tombstones and avoid heavy compaction

Regards

 Duy Hai DOAN

On Fri, May 2, 2014 at 11:40 AM, Ngoc Minh VO 
mailto:ngocminh...@bnpparibas.com>> wrote:
Hello all,

I don’t know whether it is the right place to discuss about data modeling with 
Cassandra.

We would like to have your feedbacks/recommendations on our schema modeling:

1.   Our data are stored in a CF by their unique key (K)

2.   Data type could be one of the following: Double, List, String, 
List

3.   Hence we create a data table with:

CREATE TABLE data_table (

 key text,



 numvalue double,

 numvalues list,

 strvalue text,

 strvalues list,



 PRIMARY KEY (key)

);

4.   One and only one of the four columns contains a non-null value. The 
three others always contain null.

5.   Pros: easy to debug

This modeling works fine for us so far. But C* considers null values as 
tombstones and we start having tombstone overwhelming when the number reaches 
the threshold.

We are planning to move to a simpler schema with only two columns:

CREATE TABLE data_table (

 key text,

 value blob, -- containing serialized data

 PRIMARY KEY (key)

);
Pros: no null values, more efficient in term of storage?
Cons: deserialization is handled on client side instead of in the Java driver 
(not sure which one is more efficient…)

Could you please confirm that using “null” values in CF for non-expired “rows” 
is not a good practice?

Thanks in advance for your help.
Best regards,
Minh

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified.
Do not print this message unless it is necessary,consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Re: Is the updating compaction strategy from 'sized tiered' to 'leveled' automatic or need to be done manually?

[Daniel Chia]

If you want to trigger a conversion to LCS of the on-disk sstables, doing
"nodetool compact " should achieve what you want.

Be warned, if you have a lot of data in the CF, this could potentially take
a while depending on your compaction throttling.

Thanks,
Daniel


On Sun, May 4, 2014 at 11:54 PM, Yatong Zhang  wrote:

> What you mean 'you need write to this CF'? I've changed the schema by
> using CQL3 'alter table' statments.
>
>
> On Mon, May 5, 2014 at 2:28 PM, Viktor Jevdokimov <
> viktor.jevdoki...@adform.com> wrote:
>
>>  To trigger LCS you need to write to this CF and wait when new sstable
>> flushes. I can’t find any other way to start LCS.
>>
>>
>>Best regards / Pagarbiai
>> *Viktor Jevdokimov*
>> Senior Developer
>>
>> Email: viktor.jevdoki...@adform.com
>> Phone: +370 5 212 3063, Fax +370 5 261 0453
>> J. Jasinskio 16C, LT-03163 Vilnius, Lithuania
>> Follow us on Twitter: @adforminsider
>> Experience Adform DNA 
>>  [image: Adform News] 
>> [image: Adform awarded the Best Employer 2012]
>> 
>>
>> Disclaimer: The information contained in this message and attachments is
>> intended solely for the attention and use of the named addressee and may be
>> confidential. If you are not the intended recipient, you are reminded that
>> the information remains the property of the sender. You must not use,
>> disclose, distribute, copy, print or rely on this e-mail. If you have
>> received this message in error, please contact the sender immediately and
>> irrevocably delete this message and any copies.
>>
>> *From:* Yatong Zhang [mailto:bluefl...@gmail.com]
>> *Sent:* Sunday, May 4, 2014 5:22 AM
>> *To:* user@cassandra.apache.org
>> *Subject:* Is the updating compaction strategy from 'sized tiered' to
>> 'leveled' automatic or need to be done manually? [heur]
>>
>>
>>
>> Hi there,
>>
>> I am updating compaction strategy from 'sized tiered' to 'leveled' and
>> from
>> http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandrait is 
>> said:
>>
>> When updating an existing column family, reads and writes can continue as
>> usual while leveling of existing sstables is performed in the background.
>>
>>
>>
>> But I still see many old sstables with very large size and an old file
>> date. So I am wondering is the updating of compaction done automatically?
>> If yes, is there an estimate of time it will take? If not, what's the steps
>> to do it manually?
>>
>> I've googled a lot but can't find something helpful. Thanks for any
>> feedbacks and any help is of great appreciation.
>>
>
>