|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I think the "posting configuration xml" feature is using the same code in core that reload config from disk is using, so yes it is a very likely it is a similar issue.
When we had the bug in the past it was due to the way the GerritHandler (a class in the trigger plugin) was storing each listener i.e. each GerritTrigger instance to notify when an event arrives. And when reload from disk is performed Jenkins actually creates new instances of each job and for some reason the old job instance wasn't removed from the listeners list.
We solved it by implementing the list as a HashMap with the project name as the key so when a project added itself twice the instance from the last invocation was the one saved in the map. But that caused a bug when a project was renamed, so that was fixed by using a Set instead I think, maybe that caused the original bug to reappear.
Anyways; some hints on how the flow goes during startup might be of help to anyone wanting to dig into this bug.
When Jenkins starts: PluginImpl.start() is called before any jobs are loaded. PluginImpl will instanciate a GerritHandler that handles the communication and stream-events coordination towards Gerrit.
Then when each job has been loaded GerritTrigger.start() is called, and that will add the GerritTrigger instance as a listener in GerritHandler (via a call to PluginImpl.addListener).
When a job is removed or unloaded GerritTrigger.stop is called and that will remove the GerritTrigger instance as a listener.
The same happens when you reconfigure a job in Jenkins. When save is clicked first stop will be called on the old instance of GerritTrigger, then a new instance is created by Jenkins and start is called on that.
So in theory everything should be fine, but something is handled differently when the config is changed from disk or other than clicking save in the UI.
Maybe stop is never called or called in a different order so the old instance isn't removed.
Or maybe it's a new bug completely (but probably unlikely).