After thinking about the problem in more detail have an additional question:
I can replace all of those list modifying operations with a CopyOnWriteArrayList. What is still not clear for me is, how this works if multiple objects are affected? E.g. I have a loop over a number of files that should be post-processed. The result of the post-processing is stored in a CopyOnWriteArrayList. If your background thread serializes my instance during the loop it can happen that the loop variable is already set, but the list with the results is not. That means I need some lock around the whole block of variables, or how is this handled? > Am 16.11.2021 um 18:09 schrieb Ullrich Hafner <[email protected]>: > > Thanks for this in depth description of the problem! I see how much work is > required in order to rewrite that part of the code. > >> Am 16.11.2021 um 17:42 schrieb 'Devin Nusbaum' via Jenkins Developers >> <[email protected] <mailto:[email protected]>>: >> >> The CPS VM thread is responsible for saving the Pipeline's execution state, >> so if you are using a non-blocking step execution (and it looks like you are >> <https://github.com/jenkinsci/warnings-ng-plugin/blob/e6f0b7a542d4f10c71b93925eba83e20d7caa95b/plugin/src/main/java/io/jenkins/plugins/analysis/core/steps/AnalysisExecution.java#L26>), >> it is possible that your step is executing on a background thread while the >> Pipeline program is being saved on the CPS VM thread. You should account for >> this in any mutable data reachable from non-blocking step executions that is >> part of the execution's serialized state, for example by using >> CopyOnWriteArrayList, replacing fields rather than mutating them, using >> writeReplace, etc. >> >> The exception in the Jira ticket suggests that one of the objects inside of >> one of the AnnotatedReport instances returned by a scanIssues step, which is >> stored a local variable in the user's Pipeline, is being modified. Perhaps >> the issue is that there is a filename match in the FileStatistics between >> the issues collected by the user's different parallel branches, so when this >> code >> <https://github.com/jenkinsci/forensics-api-plugin/blob/d0dc4ec448ca6c9a0d5ce8a6d39e238ba07e8c30/src/main/java/io/jenkins/plugins/forensics/miner/RepositoryStatistics.java#L242> >> runs for the first time inside of AnnotatedReport.addAll in >> PublishIssuesStep.Execution.Run it uses the exact FileStatistics instance >> from an existing AnnotatedReport instance, but when it runs after that it >> modifies the previous FileStatistics instance here >> <https://github.com/jenkinsci/forensics-api-plugin/blob/d0dc4ec448ca6c9a0d5ce8a6d39e238ba07e8c30/src/main/java/io/jenkins/plugins/forensics/miner/RepositoryStatistics.java#L256>, >> and then since the FileStatistics instance is also reachable via one of the >> AnnotatedReport local variables in the Pipeline you have a potential >> ConcurrentModificationError depending on the serialization timing. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56D693ED-8A35-427F-8BDF-AA50057AB7DC%40gmail.com.
