Instead of refilling the cache every x minutes you could implement an https://javadoc.jenkins.io/hudson/model/listeners/ItemListener.html to react on job changes. This would avoid the problem mentioned in issue 302. You would need to implement onloaded(), onUpdated(), onCreated() and onDeleted() probably. Maybe also onCopied() and onLocationChanged() depending how you internally manage the data in the cache (instead of a list you would need a map<String, ParameterizedJob> with job fullname as key).
When you have your jobs organized in folders then the getAllItems could probably be made faster by loading each folder in its own thread. But with the above approach you would need to do this only once at startup so probably not worth the effort. Regarding https://github.com/jenkinsci/generic-webhook-trigger-plugin/pull/273#pullrequestreview-1585610771 You could also investigate making your plugin extensible via an ExtensionPoint. So when others see the need for a different implementation, they could write their own plugin that just implements the ExtensionPoint From: jenkinsci-dev@googlegroups.com <jenkinsci-dev@googlegroups.com> On Behalf Of Tomas Bjerre Sent: Samstag, 13. April 2024 07:13 To: Jenkins Developers <jenkinsci-dev@googlegroups.com> Subject: Jenkins.getInstance().getAllItems(ParameterizedJob.class) slow in large installations You don't often get email from tomas.bjerr...@gmail.com<mailto:tomas.bjerr...@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> It was reported here: https://github.com/jenkinsci/generic-webhook-trigger-plugin/issues/272 That the Generic Webhook Trigger Plugin is slow in large installations. I "solved" that by adding a cache and having it configurable in the global config here: https://github.com/jenkinsci/generic-webhook-trigger-plugin/blob/generic-webhook-trigger-2.1.1/src/main/java/org/jenkinsci/plugins/gwt/global/CacheConfig.java And implemented cache here: https://github.com/jenkinsci/generic-webhook-trigger-plugin/blob/generic-webhook-trigger-2.1.1/src/main/java/org/jenkinsci/plugins/gwt/jobfinder/JobFinderImpersonater.java I'd like to get some feedback on this solution. - Does this kind of cache really belong in the plugin? - In order to invalidate the cache, the plugin starts a scheduled task. Feels fragile, hard to test and I don't know if it works after a few days of uptime. - Is there a faster way to Jenkins.getInstance().getAllItems(ParameterizedJob.class); ? - Users may not understand the effect of enabling this cache https://github.com/jenkinsci/generic-webhook-trigger-plugin/issues/302#issuecomment-2051821328 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/cbea2c0c-efa3-4ef2-813b-d8ee3658500an%40googlegroups.com<https://groups.google.com/d/msgid/jenkinsci-dev/cbea2c0c-efa3-4ef2-813b-d8ee3658500an%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/AS1PR02MB78471557F788B420E66A9BB6870B2%40AS1PR02MB7847.eurprd02.prod.outlook.com.
