Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure timeout #60

Open
achimgrimm opened this issue Oct 28, 2021 · 5 comments
Open

configure timeout #60

achimgrimm opened this issue Oct 28, 2021 · 5 comments

Comments

@achimgrimm
Copy link

I like to increase the timeouts for the migration tasks for my spring boot app.
The default timeout for my app is set to 2 seconds. I don't want to change that, as it will change the application performance.

But for the actual migration during startup, I don't mind a bigger timeout.
So it would be great to configure that specifically so that the startup does not fails.

Log message from the spring boot start:

Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'migrationTask' defined in class path resource [org/cognitor/cassandra/migration/spring/CassandraMigrationAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.cognitor.cassandra.migration.MigrationTask]: Factory method 'migrationTask' threw exception; nested exception is com.datastax.oss.driver.api.core.DriverTimeoutException: Query timed out after PT2S
@dnsbtchr
Copy link

dnsbtchr commented Oct 28, 2021

We had the exact same requirement and achieved it by setting a longer timeout for a profile called cassandra-migration in the application.conf file (see https://docs.datastax.com/en/developer/java-driver/4.0/manual/core/configuration/). It looks like this

`datastax-java-driver {

profiles {
schema-migration {
basic.request.timeout = 60 seconds
}
}
...
}`

The profile can then set on the DataStax Database class using setExecutionProfileName.
Our code for this looks like this

`log.info("Starting schema migration for keyspace[{}]", keyspaceName);

Keyspace keyspace = new Keyspace(keyspaceName);
try (Database database = new Database(cqlSessionSupplier.get(), keyspace)
    .setExecutionProfileName("schema-migration")
) {
  new MigrationTask(database, createMigrationRepository(), true).migrate();
}

log.info("Finished schema migration for keyspace[{}]", keyspaceName);`

@patka
Copy link
Owner

patka commented Nov 6, 2021

Thanks @dnsbtchr for answering this. I will create a FAQ section in the README where I put this.

@achimgrimm based on your reaction I assume this works for you :)

@achimgrimm
Copy link
Author

Hi,
I did not give it a try, as I was waiting for some more reaction. The solution will probably work fine for my use case.
But I think, adding the timeout (or maybe an optional profile) as a config would make it way easier to integrate into spring boot.

@ikstewa
Copy link
Contributor

ikstewa commented Dec 7, 2021

We were able to resolve this using profiles as mentioned above.

However there is still one case where the execution profile is not always used. When you create a new instance of the 'Database' object, it will attempt to create the 'schema_migration' and 'schema_migration_leader' tables.

Is it possible to allow the execution profile name to be passed in on construction or refactor so the table creation does not happen in the constructor?

Edit: I created a pull request here: #62

@ikstewa
Copy link
Contributor

ikstewa commented Jan 10, 2022

As of 2.5.0_v4 the execution profile can now be configured via spring: https://github.com/patka/cassandra-migration/blob/master_v4/cassandra-migration-spring-boot-starter/src/main/java/org/cognitor/cassandra/migration/spring/CassandraMigrationConfigurationProperties.java#L128-L144

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants