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

Introduce option for *NOT* connecting to cassandraQL during startup #124

Closed
JiriOndrusek opened this issue Aug 24, 2020 · 9 comments
Closed

Comments

@JiriOndrusek
Copy link

JiriOndrusek commented Aug 24, 2020

I'm working on camel-quarkus extension for CassandraQL (apache/camel-quarkus#1355)

It would be nice to use this quarkus extension.

However there is a problem, which is blocking my attempts. According to the code and quarkus blog, it is necessary to define connection parameters, which are used for connecting to CassabdraQL.

  1. In my case (and I can imagine more scenarios) are connection parameters obtained dynamically. Therefore there is no way of filling application.properties in advance.
  2. In my case (and I can imagine more scenarios) I'd like to connect to several CassandraQLs, which is not possible in case of hardcoded configuration in application.properties.
  3. I've noticed a possibility to wait for a default connection in case that target cassandraQL is not available. (attempts for creation of the connection are repeated until there is available connection). But start of the extension is not finished and it is not possible e.g. to connect to other DBs.

IMHO it would be nice, if this extension could start also in some "offline" mode, without connecting to DB. In that case it won't be possible to inject QuarkusCqlSession. But it would be possible to create similar session(s) programatically

┆Issue is synchronized with this Jira Task by Unito

@adutra
Copy link
Contributor

adutra commented Aug 24, 2020

Hi thanks for reporting this.

Have you tried disabling eager session initialization? This could be a quick win for you.

@JiriOndrusek
Copy link
Author

Thanks @adutra, this seems exactly as a solution for me. I'll try this parameter tomorrow.

@adutra
Copy link
Contributor

adutra commented Aug 24, 2020

In my case (and I can imagine more scenarios) I'd like to connect to several CassandraQLs, which is not possible in case of hardcoded configuration in application.properties.

For that I think we would need to expose the ProgrammaticDriverConfigLoaderBuilder bean somehow. We already create this bean internally, see here.

Maybe you could contribute a PR to expose that bean?

@JiriOndrusek
Copy link
Author

@adutra To be honest, for my case this 'ProgrammaticDriverConfigLoaderBuilder' is not necessary. Once extension for cassandra-quarkus is used, I can use standard code to connect to cassandra using java-driver. Though It could be nice to have it for other use cases... I'll keep that in mind and look into creation of PR if time allows.

@JiriOndrusek
Copy link
Author

@adutra Parameter eager-session-init seems to work only partially.

If parameter is set to false, the I can see in log

2020-08-25 14:32:22,621 DEBUG [com.dat.oss.qua.run.int.qua.CassandraClientStarter] (main) Not triggering eager initialization of Quarkus session at startup

application does not wait for connection, my tests are executed, but once my tests are finished, extension tries to connect again. Which means that my test execution doesn't finish.

I'm attaching trace log with my execution (there is 1 dummy test) and once camel is stopped, connection to cassandra with default values is trying to create.
trace.log

@adutra
Copy link
Contributor

adutra commented Aug 25, 2020

I think you just spotted a bug indeed. I need to investigate more, but it seems to come from the fact that we add a shutdown task to close the session, see here. I suspect that calling close() on an uninitialized proxy triggers the whole initialization procedure, and you end up with that error.

@tomekl007
Copy link
Contributor

tomekl007 commented Aug 27, 2020

The other possible solution may be:
#75
also, this task is related to #106

@JiriOndrusek
Copy link
Author

Hi @tomekl007,
with parameter eager-session-init is exactly solution, which I was trying to get.
Once issue #125 is closed, from my POV this issue could be closed.

@tomekl007
Copy link
Contributor

Closing because it is solved by the eager-session-init and #125.
@JiriOndrusek please let me know if you need any more help.

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

3 participants