Hey Aaron,
I am able to sort out the problem. Thanks anyways.
Regards,
Abhijit
2012/7/1 David Daeschler :
> Good afternoon,
>
> This again looks like it could be the leap second issue:
>
> This looks like the problem a bunch of us were having yesterday that
> isn't cleared without a reboot or a date command. It seems to be
> related to the leap second that was added between t
Sure, before I create a ticket, is there a way I can confirm that the
sstables are indeed not compressed other than running the "rebuildsstables"
nodetool command (and observing the live size go down)?
Thanks.
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2
Using Cassandra as a queue is generally thought of as a bas idea, owing to the
high delete workload. Levelled compaction handles it better but it is still no
the best approach.
Depending on your needs consider running http://incubator.apache.org/kafka/
> could you share some details on this?
>>> Can compression be changed or disabled on-the-fly with cassandra?
Yes. Disable it in the schema and then run nodetool upgradetables
As Tyler said, JDK7 is not officially supported yet and you may be running into
issues others have not found. Any chance you could downgrade one node to JDK6
an
When the data is streamed into the cluster by the bulk loader it is compressed
on the receiving end (if the target CF has compression enabled).
If you are able to reproduce this can you create a ticket on
https://issues.apache.org/jira/browse/CASSANDRA ?
Cheers
-
Aaron Morton
Like the exception says:
> Bad Request: No indexed columns present in by-columns clause with "equals"
> operator
> Same with other relational operators(<,>=,<=)
You must include an equality operator in the where clause:
That is why
> SELECT * FROM STEST WHERE VALUE1 = 10;
Works but
> SELECT *
If you are reading at QUOURM there is no problem, this is how eventual
consistency works in Cassandra.
The coordinator will resolve the differences between and the column with the
higher timestamp will win.
If the delete was applied to less then CL nodes the client should have received
a Time
Good afternoon,
This again looks like it could be the leap second issue:
This looks like the problem a bunch of us were having yesterday that
isn't cleared without a reboot or a date command. It seems to be
related to the leap second that was added between the 30th June and
the 1st of July.
See
Hello,
it is not related to cassandra/ddos.
it is kernel problems due to leap second. See
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second
On Sun, Jul 1, 2012 at 1:05 PM, ruslan usifov wrote:
> Hello
>
> We was under ddos att
Hello
We was under ddos attack, and as result we got high ksoftirqd activity
- as result cassandra begin answer very slow. But when ddos was gone
high ksoftirqd activity still exists, and dissaper when i stop
cassandra daemon, and repeat again when i start cassadra daemon, the
fully resolution of
huge great thanks it is the leap second problem!
finally I can go to bed
On Mon, Jul 2, 2012 at 12:11 AM, David Daeschler
wrote:
> This looks like the problem a bunch of us were having yesterday that
> isn't cleared without a reboot or a date command. It seems to be
> related to the lea
This looks like the problem a bunch of us were having yesterday that
isn't cleared without a reboot or a date command. It seems to be
related to the leap second that was added between the 30th June and
the 1st of July.
See the mailing list thread with subject "High CPU usage as of 8pm eastern time
adjust the timezone of java by -Duser.timezone and the timezone of
cassandra is the same with system(Debian 6.0).
after restart cassandra I found the following error message in the log file
of node B. after about 2 minutes later, node C stop responding
the error log of node B:
Thrift tran
I have a three node cluster running 1.0.2, today there's a very strange
problem that suddenly two of cassandra node(let's say B and C) was costing
a lot of cpu, turned out for some reason the "java" binary just dont
run I am using OpenJDK1.6.0_18, so I switched to "sun jdk", which works
okay.
For the create/update/deleteColumn/deleteRow test case, for Quorum
consistency level, 6 nodes, replicate factor 3, for one thread around 1/100
round, I can have this reproduced.
And if I have 20 client threads to run the test client, the ratio is bigger.
And the test group will be executed by one
Could someone please tell me where I should start looking at code to
understand how cassandra bootstrap process works? I am sure it is
complicated but I have time. Also is my understanding correct that the
new nodes that are added are not joining the ring till the bootstrap
process is complete i.e
I'm running Cassandra on Raspberry Pi (for educational reason) and have been
successfully running 1.1.0 for some time. However there is no native build of
SnappyCompressor for the platform (I'm currently working n rectifying that if I
can) so that compression is unavailable. When I try and sta
More information for others that were affected.
Our installation of java:
[root@inv4 conf]# java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
[root@inv4 conf]# uname -a
Linux inv4 2.6.32-220.4
Hi Jonathan,
Looks good, any chance of porting this fix to the 1.0 branch?
Kind regards
Joost
Sent from my iPhone
On 1 jul. 2012, at 09:25, Jonathan Ellis wrote:
> On Thu, Jun 28, 2012 at 1:39 PM, Joost van de Wijgerd
> wrote:
>> the currentThoughput is increased even before the data is me
Thank you for the mail. Same here, but I restarted the affected server
before I noticed your mail.
It affected both OpenJDK Java 6 (packaged with Ubuntu 10.04) and Oracle
Java 7 processes. Ubuntu 32 bit servers had no issues, only a 64 bit
machine.
Likely it is related to the leap second in
On Thu, Jun 28, 2012 at 1:39 PM, Joost van de Wijgerd
wrote:
> the currentThoughput is increased even before the data is merged into the
> memtable so it is actually measuring the throughput afaik.
You're right. I've attached a patch to
https://issues.apache.org/jira/browse/CASSANDRA-4399 to fix
22 matches
Mail list logo
