+1
On Wed, Jul 21, 2010 at 17:59, Eric Evans wrote:
>
> It's been the better part of a month since 0.6.3, so it's probably a
> good time to start thinking about an 0.6.4.
>
> Barring objections, I'd like to tag next Tuesday July 27, and move
> anything not completed by then to 0.6.5. As usual, i
On Thu, 2010-07-22 at 12:35 -0500, Stu Hood wrote:
> I feel like the next time we break network compatibility should be the
> last time, aka, the release when we introduce a backwards compatible
> RPC layer (Avro?), and implement support for dropping messages that a
> node can't handle.
Yeah, I th
I don't know of any, but I presume Jonathan does, else he wouldn't
have brought it up.
On Thu, Jul 22, 2010 at 16:35, Sylvain Lebresne wrote:
> What would be the pros of breaking it for 0.7 now ?
> I suppose you have something specific in mind that would break
> compatibility ?
>
> On Thu, Jul 22
What would be the pros of breaking it for 0.7 now ?
I suppose you have something specific in mind that would break
compatibility ?
On Thu, Jul 22, 2010 at 8:19 PM, Gary Dusbabek wrote:
> I think this depends on how much value users place in rolling upgrades
> (it's going to vary).
>
> My opinion
I think this depends on how much value users place in rolling upgrades
(it's going to vary).
My opinion is that we should be allowed to break it between major
versions if required.
Gary.
On Thu, Jul 22, 2010 at 11:49, Jonathan Ellis wrote:
> How useful is this to insist on, given that 0.7 thrif
> So I think we should probably try to preserve compatibility in 0.7.
We could probably limit the scope of our network compatibility to
"steady-state" messages, aka, nothing having to do with bootstrap, repair, etc.
-Original Message-
From: "Stu Hood"
Sent: Thursday, July 22, 2010 12:35p
I feel like the next time we break network compatibility should be the last
time, aka, the release when we introduce a backwards compatible RPC layer
(Avro?), and implement support for dropping messages that a node can't handle.
So I think we should probably try to preserve compatibility in 0.7.
As long as network compatibility is in place, it is possible to
incrementally upgrade a cluster by restricting thrift clients to only talk
to the 0.6 nodes until half the cluster is upgraded and then modify them to
talk to the 0.7 nodes. If networking compatibility breaks, there is no way
to avoid
How useful is this to insist on, given that 0.7 thrift api is fairly
incompatible with 0.6's? (timestamp -> Clock change being the biggest
problem there)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
This should be on the user list.
Most of what you ask can easily be found on the Cassandra wiki with a
cursory search.
On Jul 22, 2010 4:31 AM, "Boris Spasojevic"
wrote:
Hi,
Which classes in Cassandra are used to store data?
Where can I find info on how Cassandra persists data?
Is there a way t
Ran Tavory gmail.com> writes:
>
> right on! at least the screenshots look cool.
>
> On Mon, May 17, 2010 at 6:20 PM, Suguru Namura <
> namura_suguru cyberagent.co.jp> wrote:
>
> > Hi,
> >
> > I am developing the web application that can monitor and manage
> > cassandra cluster. Recently I hav
Hi Suguru,
Congratulations for your web console, it's definitively the best graphic
Cassandra console I've found so far. The problem is that we are using last
Cassandra version, 0.6.3, and the console is not showing the data, even it's
detecting the keyspaces.
Is there any way we could have it w
Hi,
Which classes in Cassandra are used to store data?
Where can I find info on how Cassandra persists data?
Is there a way to periodically take a snapshot of the persisted data
without using the thrift client API? Does Cassandra persist data in a
file on in memory?
thanks in advance,
BoriS
13 matches
Mail list logo
