Sorry, I was setting the file on my client not the server. I will make this
change and get back to you.
Thanks again for the help...
Bill-
On Feb 10, 2011 4:45 PM, "Bill Speirs" wrote:
> Doesn't seem to help, I just get a bunch of messages that look like this:
>
> DEBUG - Transport open status
Bill,
It still sounds really strange.
Can you reproduce it? And note down the steps; I'm sure people here would be
pleased to repeat it.
Regards,
Utku
On Fri, Feb 11, 2011 at 5:34 AM, Mark Guzman wrote:
> I assume this should be set on all of the servers? Is there anything in
> particular one
I assume this should be set on all of the servers? Is there anything in
particular one would look for in the log results?
On Feb 10, 2011, at 4:37 PM, Aaron Morton wrote:
> Assuming cassandra 0.7 in log4j-server.properties make it look like this...
>
> log4j.rootLogger=DEBUG,stdout,R
>
>
> A
Doesn't seem to help, I just get a bunch of messages that look like this:
DEBUG - Transport open status true for client CassandraClient
DEBUG - Status of releaseClient CassandraClient to
queue: true
DEBUG - Transport open status true for client CassandraClient
And I got those before with my other
Assuming cassandra 0.7 in log4j-server.properties make it look like this...log4j.rootLogger=DEBUG,stdout,RAOn 11 Feb, 2011,at 10:30 AM, Bill Speirs wrote:I switched my implementation to use a thread pool of 10 threads each
multi-getting 10 keys/rows. This reduces my time from 50s to 5s for
fetchin
I switched my implementation to use a thread pool of 10 threads each
multi-getting 10 keys/rows. This reduces my time from 50s to 5s for
fetching all 1,000 messages.
I started looking through the Cassandra source to find where the
parallel requests are actually made, and I believe it's in
org.apac
The out of bounds error normally means you have columns names that are not
valid time uuids.
Is that a possibility ?
Aaron
On 11/02/2011, at 5:55 AM, Bill Speirs wrote:
> We attempted a compaction to see if that would improve read
> performance (BTW: write performance is as expected, fast!).
Each message row is well under 1K. So I don't think it is network... plus
all boxes are on a fast LAN.
Bill-
On Feb 10, 2011 11:59 AM, "Utku Can Topçu" wrote:
> Dear Bill,
>
> How about the size of the row in the Messages CF. Is it too big? Might you
> be having an overhead of the bandwidth?
>
>
Dear Bill,
How about the size of the row in the Messages CF. Is it too big? Might you
be having an overhead of the bandwidth?
Regards,
Utku
On Thu, Feb 10, 2011 at 5:00 PM, Bill Speirs wrote:
> I have a 7 node setup with a replication factor of 1 and a read
> consistency of 1. I have two colum
We attempted a compaction to see if that would improve read
performance (BTW: write performance is as expected, fast!). Here is
the result, an ArrayOutOfBounds exception:
INFO 11:48:41,070 Compacting
[org.apache.cassandra.io.sstable.SSTableReader(path='/test/cassandra/data/Logging/DateIndex-e-7-Da
I have a 7 node setup with a replication factor of 1 and a read
consistency of 1. I have two column families: Messages which stores
millions of rows with a UUID for the row key, DateIndex which stores
thousands of rows with a String as the row key. I perform 2 look-ups
for my queries:
1) Fetch the
11 matches
Mail list logo
