I will try to reproduce problem on smaller test cluster.
It was rather easy, cluster contains 4 servers.
Log's fragment from restarted node (10.2.3.38):
DEBUG [pool-1-thread-64] 2009-10-15 14:18:16,290 CassandraServer.java (line 214)
get_slice
DEBUG [pool-1-thread-64] 2009-10-15 14:18:16,290
Does this still happen after a few dozen queries to 10.2.3.38?
It looks like .40 is finding the key and trying to send it back, so
one possibility is that .40's pooled socket to .38 hasn't realized
that .38 was restarted, so the first few messages might get lost
before it reconnects.
2009/10/15
Does this still happen after a few dozen queries to 10.2.3.38?
Hmm. it depends of downtime and how long it worked before restart. If both times
is rather small then errors/timeouts go away after ten minutes. If at least one
of that times is greater than half an hour then full restoration could
Using the Thrift Perl API into Cassandra, I am running into what is
endearingly referred to as the 4 bytes of doom:
TSocket: timed out reading 4 bytes from localhost:9160
The script I am using is fairly simple. I have a text file that has about
3.6 million lines that are formatted like:
What happens if you set it to 10?
On Oct 15, 2009, at 11:48 AM, Eric Lubow eric.lu...@gmail.com wrote:
My connection section of the script is here:
# Connect to the database
my $socket = new Thrift::Socket('localhost',9160);
$socket-setSendTimeout(2500);
Quicker question: Is this ColumnFamily using UTF8Type as its comparator?
On Thu, Oct 15, 2009 at 1:17 PM, Jonathan Ellis jbel...@gmail.com wrote:
The exception on restart is occurring during a compaction of
already-written sstables. It logs what the files are beforehand
(Compacting [...]).
Yes, I'm using UTF8Type as the comparator.
On Thu, Oct 15, 2009 at 11:33 AM, Jonathan Ellis jbel...@gmail.com wrote:
Quicker question: Is this ColumnFamily using UTF8Type as its comparator?
On Thu, Oct 15, 2009 at 1:17 PM, Jonathan Ellis jbel...@gmail.com wrote:
The exception on restart is
I see a similar thing happening all the time. I get around it by closing
the current connection and reconnecting after a sleep. Although I am able
to do quite a few inserts between errors, so I'm not sure if it's the
exact problem.
-Anthony
On Thu, Oct 15, 2009 at 11:26:08AM -0400, Eric Lubow
Aha! :)
Could you test the patch attached to
https://issues.apache.org/jira/browse/CASSANDRA-493 ?
(If you're using the binary release, you can get the source from
https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.0-final/
and build with ant)
thanks,
-Jonathan
On Thu,
Are you also using Perl?
On Thu, Oct 15, 2009 at 1:38 PM, Anthony Molinaro
antho...@alumni.caltech.edu wrote:
I see a similar thing happening all the time. I get around it by closing
the current connection and reconnecting after a sleep. Although I am able
to do quite a few inserts between
So I ran the tests again twice with a huge timeout and it managed to run in
just under 3 hours both times. So this issue is definitely related to the
timeouts. It might be worth changing the default timeouts for Perl to match
the infinite timeouts for Python. Thanks for the quick responses.
-e
11 matches
Mail list logo