DataStax Help Center

Cassandra 2.1 sstableloader fails with "Could not retrieve endpoint ranges"

Summary

This article discusses a known issue with loading data using sstableloader from version 2.1 of Cassandra.

Symptoms

When loading data to a cluster using sstableloader, it results in the following sample stack trace:

Could not retrieve endpoint ranges: 
java.lang.IllegalArgumentException
java.lang.RuntimeException: Could not retrieve endpoint ranges: 
        at org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:338)
        at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:156)
        at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:106)
Caused by: java.lang.IllegalArgumentException
        at java.nio.Buffer.limit(Buffer.java:267)
        at org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:543)
        at org.apache.cassandra.serializers.CollectionSerializer.readValue(CollectionSerializer.java:124)
        at org.apache.cassandra.serializers.MapSerializer.deserializeForNativeProtocol(MapSerializer.java:101)
        at org.apache.cassandra.serializers.MapSerializer.deserializeForNativeProtocol(MapSerializer.java:30)
        at org.apache.cassandra.serializers.CollectionSerializer.deserialize(CollectionSerializer.java:50)
        at org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:68)
        at org.apache.cassandra.cql3.UntypedResultSet$Row.getMap(UntypedResultSet.java:287)
        at org.apache.cassandra.config.CFMetaData.fromSchemaNoTriggers(CFMetaData.java:1833)
        at org.apache.cassandra.config.CFMetaData.fromThriftCqlRow(CFMetaData.java:1126)
        at org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:330)
        ... 2 more

Cause

The issue occurs when sstableloader attempts to read the schema tables which contain collections, specifically system.schema_columnfamilies as documented in CASSANDRA-10700.

The bug is triggered if a column has been dropped from any of the application tables at some point in the past and the call to deserialise the dropped_columns column of system.schema_columnfamilies fails resulting in the example exception above.

Workaround

Since the bug only exists in the sstableloader utility, replace the copy on the loader node with a fixed version as follows:

NOTE - The next step requires that you have a valid DataStax Academy account in order to download a zipped tarball copy of DataStax Enterprise. If you do not already have one, it is free to register online which automatically generates an account.

Step 1 - Download the latest version of DSE which ships with Cassandra 2.1:

$ curl --user <academy_email>:<academy_password> -L http://downloads.datastax.com/enterprise/dse-4.8.tar.gz | tar xz

The sstableloader in the latest DSE 4.8 release above is compatible with DSE 4.7 clusters since they are from the same 2.1 version of Cassandra.

Step 2 - Use the resources/cassandra/bin/sstableloader utility in the downloaded version from step 1 to load data into the cluster.

Solution

CASSANDRA-10700 was fixed in Cassandra 2.1.13 and is included in DataStax Enterprise releases 4.7.7+ and 4.8.4+. Upgrade to the latest release of DSE to deploy the fix to all nodes in the cluster.

See also

Cassandra JIRA - CASSANDRA-10700 sstableloader will fail if there are collections in the schema tables

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk