Defense against an exception consistently thrown when running functional tests against 1.532.1 (but not 1.540, for whatever reason):
… hudson.PluginWrapper stop
WARNING: Failed to shut down …
java.lang.NullPointerException
at jenkins.model.Jenkins.lookup(Jenkins.java:3898)
at hudson.PluginWrapper.getPlugin(PluginWrapper.java:287)
at hudson.PluginWrapper.stop(PluginWrapper.java:377)
at hudson.PluginManager.stop(PluginManager.java:650)
at org.jvnet.hudson.test.TestPluginManager.reallyStop(TestPluginManager.java:129)
at org.jvnet.hudson.test.TestPluginManager.access$000(TestPluginManager.java:55)
at org.jvnet.hudson.test.TestPluginManager$1.run(TestPluginManager.java:140)
In this case, someone tried to add an element to a persisted list, and it was added in memory but the configuration could not be saved.
Unclear whether that should even be treated as an error condition (the write failure might be transient, and a subsequent write would store the addition),
but if it should be then we should throw a simple runtime exception.
java.lang.NullPointerException
at hudson.model.queue.FutureImpl.cancel(FutureImpl.java:78)
at com.tikal.jenkins.plugins.multijob.MultiJobBuilder.perform(MultiJobBuilder.java:156)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:781)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562)
at com.tikal.jenkins.plugins.multijob.MultiJobBuild$MultiJobRunnerImpl.run(MultiJobBuild.java:70)
at hudson.model.Run.execute(Run.java:1665)
at hudson.model.Run.run(Run.java:1612)
at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:63)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:230)
Removed import that was only used to attempt to satisfy the javadoc
reference to the class.
Replaced the javadoc reference to an inner class with a fully
qualified reference to the same inner class.
Otherwise we get a bunch of pool-17-thread-5 with no clue who created so many threads or why.
Also simplifies existing code which previously had to write one-off ThreadFactory implementations just to set a name.
Retrying 3 times while waiting for 100 millis between retries (at
recreating symlink after "deleting" it). Ends up throwing FAE exception
if thrown for a 4th time in a row - as not much can be done at that
point. A warning is logged in that case, prior to throwing the last FAE.
thomas@katalisindonesia.com