that would correspond to the CompareWith I mentioned
On Sun, Jan 17, 2010 at 11:19 PM, Alex Dong alex.d...@binaryplex.com wrote:
Thanks Jonathan,
two, if you use OrderPreservingPartitioner (whcih lets you specify key
sort order)
I guess this is still a rather static approach, right?
That
if you're getting that, it doesn't think it's done bootstrapping
On Sun, Jan 17, 2010 at 9:51 PM, Todd Burruss bburr...@real.com wrote:
i'm running 0.5 RC3 and performed a load balance on one of my nodes. i see a
LOT of these exceptions in the load balanced node log. is this anything to
be
2010/1/15 Ted Zlatanov t...@lifelogs.com:
On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta tsalora...@gmail.com
wrote:
TS 2010/1/15 Ted Zlatanov t...@lifelogs.com:
Hell, let's make the query a RESTful HTTP GET, Cassandra a HTTP
server, and return the data as JSON if it's more palatable.
Are you using multiple threads?
On Mon, Jan 18, 2010 at 1:29 PM, ML_Seda sonnyh...@gmail.com wrote:
I'm inserting a lot of documents into Cassandra/Lucandra. The problem is,
the ingestion is fairly slow:
addDocument(Document doc, Analyzer analyzer)
method takes 25-50 milliseconds
Was
Thanks Jake. No, I'm currently not using multiple threads. I will do that
next.
Thanks for the link, hopefully Lucandra will support this as well.
Jake Luciani wrote:
How big are the documents? Each term requires an insert so it's def slow
on
Lucandra's side. Once the bulk insert for
i also get this error randomly!
data = client.multiget_slice(keyspace, keys, column_parent, predicate,
ConsistencyLevel.ONE)
File /home/work/common/lazyboy/connection.py, line 109, in func
return getattr(client, attr).__call__(*args, **kwargs)
File
This particular document is 8,158 bytes, and I am storing up to six fields
only one of which is indexed and stored.
indexing is taking:
Indexing Took: 14714ms*
This is problematic when I'm trying to ingest millions of documents.
Jake Luciani wrote:
How big are the documents? Each term
This is described in the Handling failure section of the Operations page.
I believe it will work even if you use the same token as the old node, yes.
-Jonathan
2010/1/18 Michael Lee mail.list.steel.men...@gmail.com:
Even good node has the same token as bad one?
Is it an 'documented'
I think you are seeing the behavior described at in
http://issues.apache.org/jira/browse/THRIFT-455, where In C++,
optional fields require applications to manually set __isset fields,
otherwise they are not serialized on writing. Apparently this is
considered a feature.
-Jonathan
On Thu, Dec
