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 <i...@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
