-
Notifications
You must be signed in to change notification settings - Fork 251
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
Reduce overhead of TogglzTestExecutionListener #914
Conversation
Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com>
Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com>
Fixed the failing |
thanks for your PR @dreis2211 :) I am back from vacation and finished all my talks and workshops. So I will have time to work on your PRs this week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense to me as well. lgtm
thanks for your PR :)
Codecov ReportBase: 54.76% // Head: 55.32% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #914 +/- ##
============================================
+ Coverage 54.76% 55.32% +0.56%
- Complexity 892 913 +21
============================================
Files 177 180 +3
Lines 4536 4593 +57
Branches 594 601 +7
============================================
+ Hits 2484 2541 +57
Misses 1890 1890
Partials 162 162
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
* Reduce overhead of TogglzTestExecutionListener Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com> * Fix InMemoryStateRepositoryTest Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com> Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com>
* Upgrade from javax to jakarta namespace, including upgrades to Spring Boot 3 and Spring 6 - Currently missing modules: CDI (some more research/help needed to fix tests), Shiro (still no jakarta version available) and Cassandra (outdated) * Fix snapshot version and re-enable ansi console * Use Java 17 in CI * Re-enable jacoco * Remove trial and error code from CDIBeanFinder * Refine some dependencies and add xml to editorconfig to keep pom formatting with 2 spaces as indent size * Also disable dynamodb (AWS Java SDK v1 is not compatible with Java 17, should be migrated) and war sample (needs some research) * Remove explicit spring core version in spring boot module * Reduce allocations from DefaultMapSerializer (#909) * Reduce overhead of TogglzTestExecutionListener (#914) * Reduce overhead of TogglzTestExecutionListener Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com> * Fix InMemoryStateRepositoryTest Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com> Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com> * Remove comment * Replace deprecated authorizeRequests method and reformat file * Keep original filterChain formatting * Remove thymeleaf version, let spring boot define it * Fix spring boot war sample * Various dependency updates * AWS SDK dependency updates * Dependency updates * Reformatting and clean up of pom.xml files * Compilation with latest htmlunit works again, had a broken local maven cache ;D * Refactor some pom.xml files * Fix CDI module, the @ApplicationScoped annotation has to be at class level to be discovered by new defaul bean-discovery-mode annotated in CDI 4.0 * Empty beans.xml is not needed for CDI anymore * Remove comment * Shiro 1.11.0 has been released with Jakarta support, so the module is re-enabled and updated --------- Signed-off-by: Christoph Dreis <christoph.dreis@innogames.com> Co-authored-by: Christoph Dreis <dreis2211@users.noreply.github.com>
Any chance this could be backported or released before 4.0.0 with all the breaking changes in it? |
Hi,
I've noticed that our test-suite spends around ~3-4% of CPU cycles just inside
TogglzTestExecutionListener
.The unfortunate bit here is that we don't even customize the feature flags in the majority of cases and deal with the default state. It seems that we could skip setting the feature flag state in those cases - which resorts to the JDBC implementation for us - and avoid the corresponding overhead. The additional benefit in our case is that the
CachingStateRepository
will have more cache hits and avoid the reading overhead from the database as well.Let me know what you think.
Cheers,
Christoph