Complete information, including everything in tpstats, is available
for your monitoring systems via JMX. For production clusters, it is
essential you at least collect the JMX stats, if not alarm on various
problems (such as backed up stages).
b
On Wed, Sep 22, 2010 at 6:47 AM, Carl Bruecken
wr
> 2-4 are bad enough risks that it's worth taking the time to get it
> right before committing it.
So what is the plan for "getting it right" then?
Is it a plan that satisfies all parties?
Can people work together on that plan?
Would be great to discuss the details on the dev list (not in JIRAs)
On Thu, Sep 23, 2010 at 6:29 PM, Peter Harrison wrote:
> On Fri, Sep 24, 2010 at 9:15 AM, Jonathan Ellis wrote:
>> Can you start with the problem you are trying to solve, before we
>> decide if composite indexes is the right solution? :)
>
> The new server side indexing function looks interesting
On Fri, Sep 24, 2010 at 8:45 AM, Chris Goffinet wrote:
> My two cents on the issue is that, it's an important feature that the
> community wants, and the work needing to be done to let 1072, isn't worth the
> amount of effort to delay at this stage. I would much rather get the code in,
> suppor
I can chime in on that part Joe. The counters weren't the reasons for launch
issues. It was just actually the volume of messages we were trying to handle in
the cluster, so it didn't matter if it was reads for counts or reads to normal
CFs, we just had more on the count side.
It is very unfortu
On Sep 24, 2010, at 8:01 AM, Jeremy Hanna wrote:
> H... would there be any way that others in the project that are familiar
> with the design could help the authors to redo some of the elements to remove
> the internal clock structure and get it to work properly before 0.7.0 is
> finalize
H... would there be any way that others in the project that are familiar
with the design could help the authors to redo some of the elements to remove
the internal clock structure and get it to work properly before 0.7.0 is
finalized? Not sure if that's feasible, but I would just hate to s
On Fri, Sep 24, 2010 at 5:39 AM, Torsten Curdt wrote:
> Cassandra is out of incubation and I am no longer on the PMC ...but this
> a little concerning.
>
> I know this discussion is all about good internal design but - for the sake
> of the community - isn't there a way this fork could be avoided?
?Apologies for my last e-mail with the misleading subject i was reading this
thread and mistakenly replied with stuff.
?I've been using Cassandra for a while now and no problems. I have a new
project coming up now that we're penciling out the data structure for.
The best we've come up with has turned into a graph structure i'm just
wanting to know what people think because i
know there are graph db's out there
I'm all for some kind of some kind of compromise. It doesn't appear to
be a niche use case for just one company. Twitter, Digg, and SimpleGeo
and several others have said they will be using high volume counters.
They have already cleaned things up and separated it out. I don't know
all the details
Cassandra is out of incubation and I am no longer on the PMC ...but this
a little concerning.
I know this discussion is all about good internal design but - for the sake
of the community - isn't there a way this fork could be avoided? I don't have
the feeling this is about the work involved implem
Here is an update to where we are at with the counters.
As promised we have published a new patch that adds a separate api method,
marked experimental, for the counters in CASSANDRA-1072.
The discussion has now moved to CASSANDRA-1502, a ticket that suggests the
internal IClock, reconciler and
Hi,
maybe you are looking for asynchronous triggers...
https://issues.apache.org/jira/browse/CASSANDRA-1311
http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
Augi
14 matches
Mail list logo
