-
Improvement
-
Resolution: Unresolved
-
Major
-
None
See this stacktrace
"SharedConfigurationSynchronizer thread" #9192 daemon prio=5 os_prio=0 tid=0x00007fb33c134000 nid=0x3718 runnable [0x00007fb336bec000] java.lang.Thread.State: RUNNABLE at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) at java.io.File.exists(File.java:819) at hudson.plugins.jobConfigHistory.HistoryFileFilter.accept(HistoryFileFilter.java:41) at java.io.File.listFiles(File.java:1291) at hudson.plugins.jobConfigHistory.FileHistoryDao.getRevisions(FileHistoryDao.java:335) at hudson.plugins.jobConfigHistory.FileHistoryDao.getRevisions(FileHistoryDao.java:325) at hudson.plugins.jobConfigHistory.FileHistoryDao.getRevisions(FileHistoryDao.java:320) at hudson.plugins.jobConfigHistory.FileHistoryDao.hasDuplicateHistory(FileHistoryDao.java:559) at hudson.plugins.jobConfigHistory.FileHistoryDao.checkDuplicate(FileHistoryDao.java:581) at hudson.plugins.jobConfigHistory.FileHistoryDao.saveItem(FileHistoryDao.java:269) at hudson.plugins.jobConfigHistory.JobConfigHistorySaveableListener.onChange(JobConfigHistorySaveableListener.java:54) at hudson.model.listeners.SaveableListener.fireOnChange(SaveableListener.java:81) at jenkins.model.Jenkins.save(Jenkins.java:3134) - locked <0x00000006c8382f38> (a hudson.model.Hudson) at hudson.BulkChange.commit(BulkChange.java:98) at com.cloudbees.opscenter.context.config.ToolsInstallerSnippetHandler.consume(ToolsInstallerSnippetHandler.java:90) - locked <0x00000006c5a42bd8> (a com.cloudbees.opscenter.context.config.ToolsInstallerSnippetHandler) at com.cloudbees.opscenter.context.config.ConfigurationSnippetRefresher.execute(ConfigurationSnippetRefresher.java:56) at hudson.model.AsyncPeriodicWork$1.run(AsyncPeriodicWork.java:100) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - None
Looking at the plugin code, it seems to actually read all existing history files for a config file just to compare the new state to the latest saved state. This should be more efficient as it only cares about the latest one anyway:
https://github.com/jenkinsci/jobConfigHistory-plugin/blob/b2d39c7a556e77c8c5bdc123b9131362ebd5d52c/src/main/java/hudson/plugins/jobConfigHistory/FileHistoryDao.java#L815
So it seems that in JCH either you don't de-duplicate, or keep short histories, for now.