Hi David,
yes, what we are working on could be referenced as "encrypted database
service".
Thanks for your insights. We will continue to work on this topic!
Kind regards
Matthias
On 10/21/2011 02:31 AM, David Jeske wrote:
If I understand you correctly, you are saying that you will never have
@Araron you're right and i was wrong!
2011/10/20 Yang
> found it , https://issues.apache.org/jira/browse/CASSANDRA-3387
>
> On Thu, Oct 20, 2011 at 1:37 PM, aaron morton
> wrote:
> > It's unlikely that HH is the issue. (Disclaimer, am not familiar with HH
> in
> > 1.0, i know it's changes a bit
I believe this is the same as
https://issues.apache.org/jira/browse/CASSANDRA-3306.
The initial reporter only got this exception with leveled compaction,
is it what you are
using too (to help narrow it down)? Also, are you using windows by any chance?
--
Sylvain
On Thu, Oct 20, 2011 at 9:04 PM,
Given the following log line:
DEBUG [ReadStage:20] 11:39:07,028 collecting 0 of 2147483647:
SuperColumn(2150726f70657274696573 [64617461:false:4@1319189945952058,])
What does "false:4" in the column mean?
Thanx!
Rene
On Fri, Oct 21, 2011 at 12:48 PM, Rene Kochen
wrote:
> Given the following log line:
>
>
>
> DEBUG [ReadStage:20] 11:39:07,028 collecting 0 of 2147483647:
> SuperColumn(2150726f70657274696573 [64617461:false:4@1319189945952058,])
>
>
>
> What does “false:4” in the column mean?
false means the col
I thought this patch made it into the 1.0 release? I remember it being
referenced in one of the re-rolls.
On Oct 20, 2011, at 9:56 PM, "Jonathan Ellis" wrote:
> That looks to me like it's reporting uncompressed size as the load.
> Should be fixed in the 1.0 branch for 1.0.1.
> (https://issues
Thank you.
Is it also possible to see whether a row is deleted using the Thrift remove
method. I.e. how can I see in the log whether or not there is a row tombstone
when retrieving the row?
(I am investigating an issue where sometimes a deleted row resurrects).
Rene
-Original Message
I could be totally wrong here, but If you are doing a QUORUM read and there is
a bad value encountered from the QUORUM won't a repair happen? I thought
read_repair_chance 0 just means it won't query extra nodes to check for bad
values.
-Jeremiah
On Oct 17, 2011, at 4:22 PM, Jeremy Hanna wrote
Are you using compressed sstables? or the leveled sstables? Make sure you
include how you are configured in any JIRA you make, someone else was seeing a
similar issue with compression turned on.
-Jeremiah
On Oct 14, 2011, at 1:13 PM, Ramesh Natarajan wrote:
> What does the Load column in node
I don't think there is a debug message showing this, but you can easily add one,
just add a log that prints the int and the int deserialized in
ColumnFamilySerializer.java
deserializeFromSSTableNoColumns() method. The int returned is the
local deletion time.
If it's not negative, it basically mean
Rock on. Thanks for the point Aaron.
We're giving this a try right now to index our column families.
cheers,
-brian
On Thu, Oct 20, 2011 at 4:26 PM, aaron morton wrote:
> Solr can use a dynamic schema…
>
>
> https://github.com/apache/lucene-solr/blob/trunk/solr/example/solr/conf/schema.xml#L53
Hello :-)
Does anyone have a working config with normal secure authentication?
I've just installed Cassandra 1.0.0 and see that SimpleAuthenticate is
meant to be non-secure and was moved to examples. I need a production
config - so I've tried to write this to config:
authenticator: org
You're right, that is in 1.0.0. Don't know what the OP is seeing, then.
On Fri, Oct 21, 2011 at 6:32 AM, Jeremiah Jordan
wrote:
> I thought this patch made it into the 1.0 release? I remember it being
> referenced in one of the re-rolls.
>
>
> On Oct 20, 2011, at 9:56 PM, "Jonathan Ellis" wro
Correct.
On Fri, Oct 21, 2011 at 6:47 AM, Jeremiah Jordan
wrote:
> I could be totally wrong here, but If you are doing a QUORUM read and there
> is a bad value encountered from the QUORUM won't a repair happen? I thought
> read_repair_chance 0 just means it won't query extra nodes to check for
Thanks a lot !
Vitaly
On Fri, Oct 21, 2011 at 1:48 AM, aaron morton wrote:
> See http://www.mail-archive.com/user@cassandra.apache.org/msg18132.html
>
> https://issues.apache.org/jira/browse/CASSANDRA-3391
>
> Cheers
>
> -
> Aaron Morton
> Freelance Developer
> @aaronmorton
> h
i am using size based compaction ( the default one ). Also this is on linux.
thanks
Ramesh
On Fri, Oct 21, 2011 at 4:25 AM, Sylvain Lebresne wrote:
> I believe this is the same as
> https://issues.apache.org/jira/browse/CASSANDRA-3306.
>
> The initial reporter only got this exception with levele
I don't use compressed sstable. I also use the default compaction
strategy. i will look at JIRA and see if there are any similarities.
thanks
Ramesh
On Fri, Oct 21, 2011 at 6:51 AM, Jeremiah Jordan
wrote:
> Are you using compressed sstables? or the leveled sstables? Make sure you
> include ho
actually this is only an issue in HH, since HH writes all the stored
messages into the same row, so locking is a problem
2011/10/21 Jérémy SEVELLEC :
> @Araron you're right and i was wrong!
>
> 2011/10/20 Yang
>>
>> found it , https://issues.apache.org/jira/browse/CASSANDRA-3387
>>
>> On Thu, Oct
Well you could use a DOUBLE value to encode relative positions...
first item in list gets key 1.0
insert before first item -> key[first]/2.0;
append after last item -> key[last]*2.0;
insert after non-final item -> (key[n]+key[n+1])/2.0
Using double precision should give you quite a space to fit i
Would you have the full log for one of those node leading to the exception
that you could share? Not sure that'll help but who knows.
--
Sylvain
On Fri, Oct 21, 2011 at 4:34 PM, Ramesh Natarajan wrote:
> i am using size based compaction ( the default one ). Also this is on linux.
>
> thanks
> Ra
All,
I have a specific question which I think highlights a general problem.
===Specific Question===
I'm seeing read times of 2-300ms for getting a single row. This seems slow,
but is it unusual?
Stack
5 node cluster
Version .86
EC2 m1large machines
ebs drives for all data (I know, I know)
Da
21 matches
Mail list logo
