The one in 0.6 doesn't allow controlling number of replicas to place in
other DC. Atmost 1 copy of data can be placed in other DC.
What are other differences between the implementation in 0.6 vs 0.7?
On Tue, Sep 21, 2010 at 10:03 PM, Benjamin Black wrote:
> DCShard is in 0.6. It has been rew
On Mon, Sep 20, 2010 at 7:25 PM, Kuan(謝冠生) wrote:
> By using cassandra-cli tool, we don't have to input timestamp while
> insertion. Does it mean that Cassandra have time synchronization build-in
> already?
No, it means the cassandra-cli program is inserting a timestamp, which
it then provides
DCShard is in 0.6. It has been rewritten in 0.7.
On Tue, Sep 21, 2010 at 10:02 PM, rbukshin rbukshin wrote:
> Is there any plan to backport DataCenterShardStrategy to 0.6.x from 0.7? It
> will be very useful for those who don't want to make drastic changes in
> their code and get the benefits of
Is there any plan to backport DataCenterShardStrategy to 0.6.x from 0.7? It
will be very useful for those who don't want to make drastic changes in
their code and get the benefits of this replica placement strategy.
--
Thanks,
-rbukshin
Yes, I think that's the one.
I imagine svn blame on NEWS would tell you for sure.
On Tue, Sep 21, 2010 at 8:05 AM, Gary Dusbabek wrote:
> 1465 maybe?
>
> On Mon, Sep 20, 2010 at 16:00, Aaron Morton wrote:
>> Just took a look upgrading from from 31/08 nightly to the 20/09 and noticed
>> the news
Disabling swap entirely is usually the easiest fix, yes.
On Mon, Sep 20, 2010 at 8:10 PM, Alaa Zubaidi wrote:
> Thanks Peter,
> I decreased the heap size, it did not help, however, it delayed the problem.
> I noticed that its swapping, so, do you think that I should set windows to
> Not to swap?
It can be useful to use a timestamp that is based on other timestamps
already in the system, rather than "the current time."
2010/9/20 Kuan(謝冠生) :
> To whom it may concern,
>
>
> While timestamp parameter is auto generated by using cassandra-cli tool, why
> user have to manually insert the parame
On Mon, Sep 20, 2010 at 4:57 PM, Peter Schuller
wrote:
>> Not in 0.6 I believe, but I believe this recently went into trunk for
>> the upcoming 0.7.
>
> By "not in 0.6" i mean in terms of the configuration.
This is ready for 0.6.6, fwiw.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-foun
Thanks for this, really interesting stuff. Just to make sure I'm understanding it, this is for PHP clients witha 1 second timeout and retry is to a different node in the cluster with the same timeout. Have you enabled the Dynamic Snitch ? http://www.riptano.com/blog/whats-new-cassandra-065AaronOn
It's best to just use timestamps as the current millisecond (or better) time and treat them as an internal implementation thing for cassandra. Playing with them will only bring you pain. As Phil says when applying a mutation, if the time stamp is less than the current value cassandra will ignore th
On Tue, Sep 21, 2010 at 8:29 AM, Juho Mäkinen wrote:
> It's known that compaction hurts the node performance so that it might
> miss some requests. That's why it's important to handle these
> situations and the client needs to retry the operation into another
> working host. We have been storing p
My experience is that timestamps have to be sequentially increasing for
writes to work. Soft/silent error if you do not follow this protocol.
Haven't tested against > 0.6.4 though.
On Tue, Sep 21, 2010 at 8:29 AM, Lucas Nodine wrote:
> Chris, I believe if the timestamp being written if the same
Pulled trunk r999443 and applied
https://issues.apache.org/jira/browse/CASSANDRA-1415 using jira-apply.
Built and ran code that used to fail and now it works.
Thanks.
CB
On Fri, Sep 17, 2010 at 9:49 AM, Jonathan Ellis wrote:
> Indexed columns don't have to exist.
>
> Try this after I post a
The standard thrift php client detects the problem by normal timeout
which triggers a TException (Thrift Exception) which indicates that
request timeouted, or the (in)famous "timed out reading 4 bytes from
". These errors are catched on my php wrapper
[http://github.com/dynamoid/cassandra-utilities
On 21-09-2010 15:29, Juho Mäkinen wrote:
It's known that compaction hurts the node performance so that it might
miss some requests. That's why it's important to handle these
situations and the client needs to retry the operation into another
working host. We have been storing performance data fr
On Tue, Sep 21, 2010 at 5:01 PM, Morten Wegelbye Nissen wrote:
> There is a point here that is very important. The key, is erhhm the key to
> success. Ie. you must build the key in a way where you can find it again.
Yes. You must index your data (choose your key and column names) in
such that it
Thanks,
There is a point here that is very important. The key, is erhhm the key
to success. Ie. you must build the key in a way where you can find it again.
In case you create a system for login, you would most likely have the
login name as key. ( And maybe here link that to a userid that wi
It's known that compaction hurts the node performance so that it might
miss some requests. That's why it's important to handle these
situations and the client needs to retry the operation into another
working host. We have been storing performance data from each
cassandra request which we do into o
1465 maybe?
On Mon, Sep 20, 2010 at 16:00, Aaron Morton wrote:
> Just took a look upgrading from from 31/08 nightly to the 20/09 and noticed
> the news.txt says...
> "The Cassandra inter-node protocol is incompatible with 0.6.x releases (and
> with 0.7 beta1)"
> Could someone point me to the tick
Not really. The schema has worked without any problems and we haven't
had any problems with it. We're running a five node cassandra cluster
behind the system (it has also other uses than just this particular
application like it stores all our blog contents and bunch of other
data). There are about
Chris, I believe if the timestamp being written if the same or older it will
not apply the write, but do not quote me on this, test it. In this case, if
the timestamp value does not matter, you could simply always write with a
timestamp of 1.
- LN
On Tue, Sep 21, 2010 at 5:58 AM, Christian Decke
In theory you could use timestamps that go back in time for this CF. That way
the first write will persist over future writes.
On Sep 21, 2010, at 6:58 AM, Christian Decker
wrote:
> Hi all,
>
> I have a rather strange problem I'd like to address. As I understand it a
> write in cassandra
Thanks for the writeup...good stuff!
Any lessons learnt you'd like to share or challenges that persist?
Simon Reavely
On Sep 20, 2010, at 6:37 AM, Juho Mäkinen wrote:
> We have built a facebook style "messenger" into our web site which
> uses cassandra as storage backend with two column famil
Hi all,
I have a rather strange problem I'd like to address. As I understand it a
write in cassandra always overwrites already existing data, so it is not
possible to have a way to create an index pointing to the first entry
matching some criteria. What I mean is that I have a CF which stores user
> I decreased the heap size, it did not help, however, it delayed the problem.
> I noticed that its swapping, so, do you think that I should set windows to
> Not to swap?
I'm not sure what's best done on Windows. For Linux/Unix there is
some discussion on:
https://issues.apache.org/jira/brows
25 matches
Mail list logo
