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

Triggering timer less often and fixing few typos #183

Conversation

shravaniPshetty
Copy link
Contributor

Note that the main branch points at the latest stable Camel Quarkus release.
Pull requests should be generally send against the camel-quarkus-main branch pointing at the current Camel Quarkus SNAPSHOT.

@aldettinger
Copy link
Contributor

@spatnity Thanks for contribution. Wouldn't it be more robust to have the value of period different in test and prod environment ? Like what was done for the delay in in DerbyDataSource.

@shravaniPshetty
Copy link
Contributor Author

Can anyone give me some idea on why some checks are failing here?

@zhfeng
Copy link
Contributor

zhfeng commented Nov 28, 2023

@spatnity Please see #182 (comment) and I think we need to wait @jamesnetherton to do upgrade main branch after 3.6.0 is released.

@shravaniPshetty
Copy link
Contributor Author

Thanks @zhfeng , got it!

@aldettinger
Copy link
Contributor

@spatnity Meanwhile, it could be good opportunity to implement a timer period different in test and prod environment ? Like what was done for the delay in in DerbyDataSource.

Feel welcome to ask questions if reason to do this or implementation is not clear :)

@shravaniPshetty
Copy link
Contributor Author

Yeah sure looking into it.

@shravaniPshetty
Copy link
Contributor Author

@aldettinger may i know what does i mean when u say test and prod environment?
and also here in the commit, I have this https://github.com/apache/camel-quarkus-examples/pull/183/files#diff-cb496e7b34f628e54aef57972f5bf8b2a122477f942147f9b5160553218e8a91R35
so is it required ?

@aldettinger
Copy link
Contributor

@spatnity Yes sure. Let's try to explain better. In the mentioned commit, the period endpoint query option of the timer component has value 10000 ms. This is good as when we execute the route, we see messages at a human friendly pace.

However, during tests we also wait for 10s at least, it's quite long. So the idea would be to have timer.period value of 100ms only during tests, e.g. during mvn clean test. Overriding configuration during tests is a common trick commonly used. An example of such trick could be found in the jpa-idempotent-repository folder:

[main_upstream @ jpa-idempotent-repository]$ grep -R timer.period
src/main/java/org/acme/jpa/idempotent/repository/ExampleHarnessRoutes.java:        from("timer:createExampleInputFiles?delay={{timer.delay}}&period={{timer.period}}&repeatCount={{timer.repeatCount}}")
src/main/resources/application.properties:timer.period = 10000
src/test/java/org/acme/jpa/idempotent/repository/DerbyTestResource.java:                    "jdbc:derby://localhost:" + container.getMappedPort(DERBY_PORT) + "/my-db", "timer.period", "100",

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

Successfully merging this pull request may close these issues.

4 participants