-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Powered by SuggestiMate
Using the parameterized build trigger and email-ext
1) Create downstream job that emails the requestor using email-ext
2) Create upstream [Edit: multi-configuration only!] job that triggers downstream job using a condition to run the parameterized build trigger plugin
3) Run upstream job: receive null ptr exception when email-ext tries to email requestor.
- is related to
-
JENKINS-12300 Null pointer exception when downstream job is run from a Build Step where email Requester is selected
-
- Resolved
-
[JENKINS-12410] Downstream jobs not associated with upstream parent job properly
- Does it always happen?
- Would you attach build.xml of the build raised the error?
The problem used to be permanent in my case. The good news is that I cannot reproduce it anymore. I tried to reproduce it in two different environments without luck:
Env 1: Jenkins 1.509.4 + Email Extension 2.36 + Parameterized Trigger 2.22
Env 2: Jenkins 1.532.2 + Email Extension 2.37.2 + Parameterized Trigger 2.22
I cannot comment on the original problem regarding multi-configuration projects though.
I could not reproduce the problem, too.
Jenkins 1.532.1 + Email-ext 2.37.2 + Parameterized-trigger 2.22.
What I tried:
- Run parameterized trigger without parameters as a publisher from multi-configuration project, and always send email to requester in the downstream.
- Run non-blocking parameterized trigger without parameters as a builder from multi-configuration project, and always send email to requester in the downstream.
- Run blocking parameterized trigger without parameters as a builder from multi-configuration project, and always send email to requester in the downstream.
I think it is already resolved in some version:
- There is another ticket
JENKINS-12300, which seems same to this and it is reported as resolved (I'm not sure how it is resolved). - Current codes of email-ext seems completely different from that of Email-ext 2.28.
I'll close this ticket as Resolved if there is no new reports in one month.
We are experiencing this. We have a job flow like Detect -> Monitor -> Deploy -> Test1 -> Test2 -> Test3 -> Upload -> Report -> Delete.
Not all the VMs we deploy are being deleted. Upon investigation, when I looked at the Delete job at the top of its console output, it shows the chain of jobs that ran.
However, when I then looked at "Deploy+1", it ran "Test1+1", but looking in that job's console output, it shows it ran Test2 – not "Test2+1"!
We are using the Parameterized Trigger Plugin (latest version, 2.25), as well as Email-Ext (latest version, 2.38.1).
@kbeal I cannot get what you say at all.
What is VM? I cannot get how a virtual machine relates to this problem.
What is +1?
Which job reported NPE?
The "Deploy" part creates a VM; the "Delete" part deletes it.
It looks like Jenkins is "getting confused" because we're seeing one job flow "merge" with another. Specific numbers:
Detect #33086 -> Monitor #637 -> Deploy #531 -> Test1 #413 -> Test2 #360 -> Test3 #308 -> Upload #301 -> Report #305 -> Delete #318
Detect #33142 -> Monitor #641 -> Deploy #532 -> Test1 #414 -> Test2 #360
Looking at Test2 #361, it appears to have crashed, which may be why Jenkins then "decided" that Test1 #414 -> Test2 #360.
So "Test2+1" would have been #361, which was expected, not #360 which we saw in the console output of Test1 #414 (as well as #413).
At the very least it should say build #361 ran, but likely there's stuff happening after the build is started that records back to the upstream job? (An odd design, it should know it's #361 at the time it started – which is, understandably, a little bit after Test1 finished, but that information should have been set a moment after #361 started, and not be "corrupted" by #361 crashing hours later – note that this job takes 4-8 hours to run, and generates a large log, around 575 MB, in case that's relevant.)
The crash from Test2 #361 is below, to the end of this comment. It was run on a slave ("slave3"), which #360 was also built on (e.g., it's not always crashing when it is run on this slave).
The beginning of the below is the end of a SOAP call, which is part of the tests that are run, and then it crashed. #361's log was only 80 MB, as it crashed 1 hour 22 min in. #360's log was 575 MB, and ran for 4 hours 40 minutes.
===================================================
[...]
[testng] </SOAP-ENV:Body>
[testng] </SOAP-ENV:Envelope>
[testng]
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:739)
at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
at $Proxy70.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951)
at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:745)
at hudson.model.Build$BuildExecution.build(Build.java:198)
at hudson.model.Build$BuildExecution.doRun(Build.java:159)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518)
at hudson.model.Run.execute(Run.java:1704)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:802)
at hudson.remoting.Channel$2.terminate(Channel.java:483)
at hudson.remoting.AbstractByteArrayCommandTransport$1.terminate(AbstractByteArrayCommandTransport.java:72)
at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:184)
at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:563)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Failed to abort
... 9 more
Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:136)
at org.jenkinsci.remoting.nio.FifoBuffer.receive(FifoBuffer.java:306)
at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:496)
... 7 more
@kbeal I cannot get why you thouht your problem relates to this issue at all.
It sounds that your problem rather relates to JENKINS-7557.
I have two free-style projects. The upstream project has a manual promotion process that triggers the downstream project. Jenkins default promotion action Build other projects works as expected whereas promotion actions Trigger/call builds on other projects and Trigger parameterized build on other projects by Parameterized Trigger plugin result in the following exception in the downstream project when trying to send an email to requesters. There is no additional info in jenkins log file, it just repeats the stack dump.
Jenkins 1.480.3, Email-ext 2.28, Parameterized Trigger 2.17