:
> Let's start wth the low-hanging fruit: can you give steps to reproduce
> queries that fail right away?
>
> On Wed, Nov 17, 2010 at 10:37 AM, dragos cernahoschi
> wrote:
> > Back. I've tested the keys index pagination once again. 0.7 head. Smaller
> > data set
mns that fail right away
with time out (count 10, 100).
Dragos
On Mon, Nov 15, 2010 at 2:29 PM, Jonathan Ellis wrote:
> On Mon, Nov 15, 2010 at 5:57 AM, dragos cernahoschi
> wrote:
> > I've tested 0.7-beta3 branch index feature without the 1472 patch. The
> > queries on mo
, Jonathan Ellis wrote:
>
> > Is it worth testing 0.7-branch-without-1472 to make sure of that?
> >
> > On Fri, Nov 12, 2010 at 10:28 AM, Stu Hood wrote:
> > > Great, thanks for the variable Dragos: I'm fairly sure I broke this in
> > the
> > >
No problem. I'll do the test on Monday.
On Nov 14, 2010 2:35 AM, "Stu Hood" wrote:
> Is it worth testing 0.7-branch-without-1472 to make sure of that?
Dragos: if you have time, this would be helpful. If you already have a KEYS
index created, you shouldn't need to re-load the data, as the file fo
x27;t going into some kind of infinite loop?
>
> Thanks for the help,
> Stu
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 11:50am
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-1472 (bitmap indexes)
>
> I
of infinite loop?
>
> Thanks for the help,
> Stu
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 11:50am
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-1472 (bitmap indexes)
>
> I'm running the qu
>
> Thanks!
>
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 10:14am
> To: dev@cassandra.apache.org
> Subject: Re: CASSANDRA-1472 (bitmap indexes)
>
> Meantime the number of SSTable(s) reduced to just 7. Initiall
dex
> for each sstable: if it finds matches it will need to seek to find them in
> the primary index, and seek again for the data file.
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Tuesday, November 9, 2010 5:33am
> To: dev@cassandra.apache.org
>
st
> case for a GT/LT query (one per index bucket).
>
> A future version might remove that requirement, but for now, you should
> probably bump the file handle limit on your machine to at least 2^16.
>
> Thanks,
> Stu
>
>
> -Original Message-
> From: &qu
Hi,
I've got an exception during the following test:
test machine: core 2 duo 2.93 2GB RAM Ubuntu 10.04
test scenario:
- 1 column family
- about 15 columns
- 7 indexed columns (bitmap)
- 26 million rows (insert operation went fine)
- thrift "query" on 3 of the indexed columns with get_indexed_sl
Patches applied. Exception disappeared.
On Mon, Nov 1, 2010 at 7:37 PM, Stu Hood wrote:
> trunk @ r1029546
>
> -Original Message-
> From: "dragos cernahoschi"
> Sent: Monday, November 1, 2010 12:20pm
> To: dev@cassandra.apache.org
> Subject: Re: more
!
>
>
> -Original Message-----
> From: "dragos cernahoschi"
> Sent: Friday, October 29, 2010 10:38am
> To: dev@cassandra.apache.org
> Subject: more info CASSANDRA-1472
>
> The stress.py command:
>
> 1. python contrib/py_stress/stress.py -C 32 -x keys
The stress.py command:
1. python contrib/py_stress/stress.py -C 32 -x keys_bitmap
2. more info from stack trace:
10/10/29 18:15:28 INFO db.Memtable: Writing
memtable-standa...@23048841(17806140
bytes, 349140 operations)
10/10/29 18:15:29 INFO service.GCInspector: GC for PS MarkSweep: 789 ms,
717
Hi,
1. I've tried to apply the patches for this bug. They worked except for the
unit test modifications that git refused to apply.
2. After applying the patches I've run the stress.py script (with 500,000
keys). The script output seems to be fine, but the cassandra console
contains the below exce
14 matches
Mail list logo
