cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: BulkLoading sstables from v1.0.3 to v1.1.1
Date Thu, 12 Jul 2012 04:11:06 GMT
Do you have the full error logs ? Their should be a couple of caused by: errors that will help
track it down where the original Assertion is thrown.

The second error is probably the result of the first. Something has upset the SSTable tracking.


If you can get the full error stack, and some steps to reproduce, can you raise a ticket on
https://issues.apache.org/jira/browse/CASSANDRA ? 

Thanks


-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 10/07/2012, at 7:43 PM, rubbish me wrote:

> Thanks Ivo. 
> 
> We are quite close to releasing so we'd hope to understand what causing the error and
may try to avoid it where possible. As said, it seems to work ok the first time round. 
> 
> The problem you referring in the last mail, was it restricted to bulk loading or otherwise?
> 
> Thanks
> 
> -A
> 
> Ivo Meißner <info@overtronic.com> 於 10 Jul 2012 07:20 寫道:
> 
>> Hi,
>> 
>> there are some problems in version 1.1.1 with secondary indexes and key caches that
are fixed in 1.1.2. 
>> I would try to upgrade to 1.1.2 and see if the error still occurs. 
>> 
>> Ivo
>> 
>> 
>> 
>>> 
>>> 
>>> Hi 
>>> 
>>> As part of a continuous development of a system migration, we have a test build
to take a snapshot of a keyspace from cassandra v 1.0.3 and bulk load it to a cluster of 1.1.1
using the sstableloader.sh.  Not sure if relevant, but one of the cf contains a secondary
index. 
>>> 
>>> The build basically does: 
>>> Drop the destination keyspace if exist 
>>> Add the destination keyspace, wait for schema to agree 
>>> run sstableLoader 
>>> Do some validation of the streamed data 
>>> 
>>> Keyspace / column families schema are basically the same, apart from in the one
of v1.1.1, we had compression and key cache switched on. 
>>> 
>>> On a clean cluster, (empty data, commit log, saved-cache dirs) the sstables loaded
beautifully. 
>>> 
>>> But subsequent build failed with 
>>> -- 
>>> [21:02:02][exec] progress: [<snip ip_addresses>]... [total: 0 - 0MB/s (avg:
0MB/s)]ERROR 21:02:02,811 Error in ThreadPoolExecutorjava.lang.RuntimeException: java.net.SocketException:
Connection reset 


Mime
View raw message