well, that didn't go away after I remove all the caches. What should I do
now?
On Wed, Oct 10, 2012 at 2:15 PM, Manu Zhang wrote:
> exception encountered during startup: Attempting to load already loaded
> column family system_traces.sessionsjava.lang.RuntimeException: Attempting
> to load alrea
The example used ONE but the hinted hand off is still performed for every
10 minutes
On Wed, Oct 10, 2012 at 10:25 AM, CharSyam wrote:
> if you don't use Write Level ANY, It will be automactically turned off.
>
> Just use Write Level One.
>
>
> 2012/10/9 Manu Zhang
>
>> Hi, all
>>
>> I tried ou
if you don't use Write Level ANY, It will be automactically turned off.
Just use Write Level One.
2012/10/9 Manu Zhang
> Hi, all
>
> I tried out the client_only example as another local node 127.0.0.2 and
> then it went down. Now the node (127.0.0.1) started hinted handoff to
> iteself. How to
> or how to solve it?
Simple solution is move to m1.xlarge :)
> In the last 3 days I see many messages of "READ messages dropped in last
> 5000ms" on one of my 3 nodes cluster.
The node is not able to keep up with the load.
Possible causes include excessive GC, aggressive compaction, or simply
Aaron,Thank you for your answer, I tried to move to Cassandra 1.1.5, but the
error still occurs.When I set a single task or less per hadoop node, the error
does not happen.However, when I have more than one task on any of the nodes
(Hadoop only node or Hadoop+Cassandra node),the error happens.
I'm not a Cassandra dev, so take what I say with a lot of salt, but
AFAICT, there is a certain amount of overhead in maintaining a CF, so
when you have large numbers of CFs, this adds up. From a layperson's
perspective, this observation sounds reasonable, since zero-cost CFs
would be tantamount to
On Tue, Oct 9, 2012 at 8:56 PM, Oleg Dulin wrote:
> My understanding is that the repair has to happen within gc_grace period.
>
> But in 1.1.1 you can set gc_grace by CF. A couple of my CFs that are
> frequently updated have gc_grace of 1 hour, but we do run a weekly repair.
>
> So the question is
Something, somewhere, at some point is breaking the connection. Sorry I cannot
be of more help :)
Something caused the streaming to fail, which started a retry, which failed
because the pipe was broken.
Are there any earlier errors in the logs ?
Did this happen on one of the nodes that has bo
Java abstracts you from all these problems. One thing to look out for
is JVM options do not work across all JVMs. For example if you try to
enable
https://wikis.oracle.com/display/HotSpotInternals/CompressedOops on a
32bit machine the JVM fails to start.
On Tue, Oct 9, 2012 at 1:45 PM, Brian Tarbo
My understanding is that the repair has to happen within gc_grace period.
But in 1.1.1 you can set gc_grace by CF. A couple of my CFs that are
frequently updated have gc_grace of 1 hour, but we do run a weekly
repair.
So the question is, is this still needed ? Do we even need to run
nodetool
> RF=2
I would recommend moving the RF 3, the QUOURM for 2 is 2.
> We can't find anything in the cassandra logs indicating that something's up
> (such as a slow GC or compaction), and there's no corresponding traffic spike
> in the application either
Does the CPU load correlate with compaction
I can't imagine why this would be a problem but I wonder if anyone has
experience with running a mix of 32 and 64 bit nodes in a cluster.
(I'm not going to do this in production, just trying to make use of the
gear I have for my local system).
Thanks.
This is a problem for us as well.
Our current planned approach is to parse the logs for repair errors.
Having nodetool repair return an exit code for some of this failures
would be *very* useful.
Cheers,
Edward
On 12-10-08 06:49 PM, David Daeschler wrote:
Hello.
In the process of trying to s
Oh, and from what I understand, the main differences between CQL and
Scalable SQL(PlayOrm) is
1. Scalable SQL can do left outer joins and inner joins currently
2. Scalable SQL does not need a compound primary key
3. Scalable SQL can partition by 2 and even 3 different columns so it is
sort of havi
If I understand CQL correctly, behind the scenes in wide rows, there is a
B-tree. Even when doing the indexing in CQL, there is a B-tree, so CQL,
Playorm, they all are really just using a wide row approach basically. I don't
think you can avoid that. Behind the scenes, they are using the "com
Thanks . This is what i have tried with cqlsh client.
Is there any comparison matrix available with b/w PlayOrm and cqlsh command
line client? Interesting to look into if it is faster than cql client.
I guess problem is with secondary indexing not the volume, because i don't
want to go for wide r
It works pretty fast.
Cool.
Just keep an eye out for how big the lucene token row gets.
Cheers
Indeed, it may get out of hand, but for now we are ok -- for the
foreseable future I would say.
Should it get larger, I can split it up into rows -- i.e. all tokens
that start with "a", all t
Looks like i got the answer:
Composite keys means it now makes sense for CQL to sport the ORDER BY
syntax in SELECT queries as well, but it’s still not nearly as flexible as
you might be used to, doing ad-hoc queries in SQL. ORDER BY clauses can
only select a single column, *and* that column has
Hi,
Create a column family:
CREATE TABLE altercations (
instigator text,
started_at timestamp,
ships_destroyed int,
energy_used float,
alliance_involvement boolean,
PRIMARY KEY (instigator,started_at,ships_destroyed);
Keyspace: testcomp:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [datacenter1:1]
Column Families:
ColumnFamily: altercations
Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Default column value vali
1 strange issue with 1.1.5 .
It works with CQL3:
**8
CREATE TABLE altercations (
...instigator text,
...started_
Works fine with 1.1.5
Thanks,
-Vivek
On Tue, Oct 9, 2012 at 1:59 PM, Vivek Mishra wrote:
> I am going to try it on 1.1.5
>
> In case if you can point me to changes made in between since 1.1.2 to
> 1.1.5 . It will be great.
>
> -Vivek
>
>
> On Tue, Oct 9, 2012 at 1:51 PM, Sylvain Lebresne wrote:
I am going to try it on 1.1.5
In case if you can point me to changes made in between since 1.1.2 to 1.1.5
. It will be great.
-Vivek
On Tue, Oct 9, 2012 at 1:51 PM, Sylvain Lebresne wrote:
> On Tue, Oct 9, 2012 at 9:50 AM, Vivek Mishra
> wrote:
> > Unfortunately nothing in server logs leads me
On Tue, Oct 9, 2012 at 9:50 AM, Vivek Mishra wrote:
> Unfortunately nothing in server logs leads me to any error.
Ok. Would you mind checking if you can reproduce against 1.1.5 if you
haven't already. If it does, do you mind opening a JIRA ticket with
the steps to reproduce?
Thanks,
Sylvain
>
>
On Tue, Oct 9, 2012 at 8:57 AM, Vivek Mishra wrote:
> Ok. I am able to understand the problem now. Issue is:
>
> If i create a column family altercations as:
>
> **8
> CREATE TABLE altercations
Also, it results in "Broken pipe" error on cqlsh. Not sure why socket
connection got broken as well.
-Vivek
On Tue, Oct 9, 2012 at 1:20 PM, Vivek Mishra wrote:
> Unfortunately nothing in server logs leads me to any error.
>
> -Vivek
>
>
> On Tue, Oct 9, 2012 at 1:16 PM, Sylvain Lebresne wrote:
Unfortunately nothing in server logs leads me to any error.
-Vivek
On Tue, Oct 9, 2012 at 1:16 PM, Sylvain Lebresne wrote:
> On Tue, Oct 9, 2012 at 8:57 AM, Vivek Mishra
> wrote:
> > Ok. I am able to understand the problem now. Issue is:
> >
> > If i create a column family altercations as:
> >
Yeah, you might want to check 1.1.5, 1.1.2 is so ancient :)
--
Sylvain
On Tue, Oct 9, 2012 at 9:44 AM, Vivek Mishra wrote:
> I am trying it with 1.1.2 cassandra release.
>
> -Vivek
>
>
> On Tue, Oct 9, 2012 at 1:13 PM, Sylvain Lebresne
> wrote:
>>
>> On Tue, Oct 9, 2012 at 3:59 AM, Vivek Mi
I am trying it with 1.1.2 cassandra release.
-Vivek
On Tue, Oct 9, 2012 at 1:13 PM, Sylvain Lebresne wrote:
> On Tue, Oct 9, 2012 at 3:59 AM, Vivek Mishra
> wrote:
> > it is giving me an error:
> >
> > [timestamp out of range for platform time_t]
>
> Hum, I can't reproduce that with the current
On Tue, Oct 9, 2012 at 3:59 AM, Vivek Mishra wrote:
> it is giving me an error:
>
> [timestamp out of range for platform time_t]
Hum, I can't reproduce that with the current 1.1 branch (nor in
trunk). So my bet is that this was an error from cqlsh that has been
fixed recently. A quick JIRA search
> Is it not possible to include a column in both the set clause and in the
> where clause?
No it's not. Or rather in that case what is not supported is the use
of secondary indexes in update where clauses. But if 'locked' is
indeed not part of your primary key, then at least the error message
suc
31 matches
Mail list logo
