Lazy converter seems to trigger "Tried to execute unprepared query ... but we don't have the data to reprepare it."

[thst71]

Hi,

we are running spring-data-cassandra 3.2.2 with spring-boot 2.5.2

We have been hit by the unprepared query issues and could resolve some of the issues with the update to SB 2.5.2.

Yet, we still get the exception and we consider that it may be because of a lazy converter, that we use and that worked great with the 2.2.x version of SB (Driver V3)

The converter-config looks like this:

public class CassandraConvertersConfiguration {

    private final AvroSerializer avroSerializer;
    private final AvroDeserializer avroDeserializer;

    public CassandraConvertersConfiguration(AvroSerializer avroSerializer, AvroDeserializer avroDeserializer) {
        this.avroSerializer = avroSerializer;
        this.avroDeserializer = avroDeserializer;
    }

    @Bean
    public CassandraCustomConversions customConversions() {
        return new CassandraCustomConversions(asList(
                new LazyAvroWriteConverter(avroSerializer),
                new LazyAvroReadConverter(avroDeserializer)
        ));
    }
}

The Lazy Converter is like this:

public class LazyAvroReadConverter implements Converter<ByteBuffer, Avro<?>> {

    private final AvroDeserializer avroDeserializer;

    public    LazyAvroReadConverter(AvroDeserializer avroDeserializer) {
        this.avroDeserializer = avroDeserializer;
    }

    @Override
    public Avro<?> convert(@NonNull ByteBuffer source) {
        return new LazyAvro<>(() -> avroDeserializer.deserialize(source.array()));
    }
}

Please remark the lambda in the convert function.

The reasonable behind this is, that the conversion shall only take place, when the value is actually used. As long as objects are "just forwarded", nothing is supposed to happen.

The issue seems to be, that the lambda can get lost in the weak-references cache in the driver. But I don't know enough of the mechanics between the Mapper / Converter and the prepared statement cache in cassandra driver.

Is this pattern disallowed or is there a smarter way to avoid unneccessary ser/deser operations?

Thank you for the support!

Update: In the comments below an important fact is added: The code uses plain cassandra repositories, no PreparedStatements are created in the application itself.

[mp911de]

Tried to execute unprepared query originates from the driver where the driver handles reprepare calls. Take a look at https://datastax-oss.atlassian.net/browse/JAVA-2910.

Generally speaking, do not select data unless you want to use it. If a column isn't selected, then the converter isn't being used as Spring Data doesn't convert null values. Converters are uses during the object mapping process after retrieving ResultSet while materializing the object to return. The converter is essentially just a function to convert one value into another, without any caching or other invisible mechanics around the source/target value.

I'm inclined to close this issue in favor of the driver-side ticket.

[thst71]

Thanks for taking the time looking at the example. In the meantime, we have experienced the issue also in other situations, but the closure-type together with a REST call seems to be especially effective to trigger the exception.

We are aware of issue JAVA-2910 and we updated to spring-boot 2.5.2 to fix the issue, but this did not help.

The fix, that works for us over the weekend, is to explicitly set the weak-references: false in the driver config:

datastax-java-driver {
    advanced.prepared-statements {
        prepared-cache {
          weak-values: false
        }
    }
}

But: I need to express this very clear: We do NOT use any prepared statements. We use ONLY spring-data generated repositories. I do not see it in the responsibility of the application nor do I see any possibility at all, to keep the prepared statements of the repositories alive.

How can the repositories loose track of prepared statements, so that these are GCed?

Update: I do not want to sound harsh, we are just using spring-data-cassandra as it is documented to our knowledge, but how can we avoid the unprepared issue in this case?

[mp911de]

Thanks for your feedback.

We do NOT use any prepared statements.

Is an important data point, as that wasn't clear from the initial description. As of version 3.2, Spring Data Cassandra uses prepared statements by default for CassandraTemplate and repositories. You can disable prepared statement usage by setting:

CassandraTemplate template = …;

template.setUsePreparedStatements(false);

and your issue should be resolved. Prepared statement caching happens within the driver, Spring Data doesn't hold references to prepared statements nor their values.

[thst71]

Will creating a CassandraTemplate as you describe it also disable the prepared statements for repositories or is this a configuration option in application.yml or a CasssandraTemplateBuilderCustomizer (exists?)

[mp911de]

CassandraTemplate is created by default with prepared statements enabled. When using Spring Boot, you can either create CassandraTemplate yourself as there isn't much to configure or you can use a BeanPostProcessor to set that property.

[thst71]

Cool, I guess this is a solution then:

    @Bean
    public CassandraTemplate cassandraTemplate(SessionFactory sessionFactory,
            CassandraConverter converter) {
        CassandraTemplate cassandraTemplate = new CassandraTemplate(sessionFactory, converter);
        cassandraTemplate.setUsePreparedStatements(false);
        return cassandraTemplate;
    }

[mp911de]

Thanks a lot. I'm closing this issue. I assume this will serve as documentation for future reports related to weak references in combination with reprepares.