So I tried to reduce the code as much as possible to see where the problem
is.
It should be wither with "ZeroTurnaround Zip library -
https://mvnrepository.com/artifact/org.zeroturnaround/zt-zip"; or "Apache
HTTP Client -
https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient";.
For now I kept only the code that zips a file and then pressed cancel job
while it was zipping a file.
In the terminal from where I run mvn hpi:run now I get
---
INFO: test2 #17 aborted
java.lang.InterruptedException
at hudson.model.Build$BuildExecution.build(Build.java:214)
at hudson.model.Build$BuildExecution.doRun(Build.java:163)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
at hudson.model.Run.execute(Run.java:1727)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
--
But in Jenkins build log it just stops and nothing is displayed.
If I cancel a job with just Thread.sleep in it I do get
---
Build was aborted
Aborted by unknown
Finished: ABORTED
---
in the build log, which is what the normal functionality should be.
So if I cancel during the zip process it kind of works but just half. No
idea why the logs are missing the "Finished: ABORTED" part.
If I cancel during the HTTP upload part there I get
the java.nio.channels.ClosedByInterruptException
On Wednesday, March 21, 2018 at 5:32:21 PM UTC+2, Jesse Glick wrote:
>
> On Wed, Mar 21, 2018 at 7:12 AM, Daniel Anechitoaie
> <[email protected] <javascript:>> wrote:
> > [Is it] possible maybe one of these libraries? […]
> >
> > I tried a test with just a bunch of Thread.sleep() before it gets to my
> code
> > (that zips the files and HTTP puts them) and if I cancel the job there
> it
> > gets aborted nicely and is handled properly by Jenkins.
>
> So sounds like a problem in the interaction between the behavior of
> those libraries and Jenkins interrupt handling. Again I suspect that
> something is catching interrupts, proceeding without throwing
> `InterruptedException`, but then setting the thread interrupt flag and
> this gets ignored up until the moment the build record is being
> finalized and the NIO calls made from `AtomicFileWriter` check the
> flag. If true, the solution would probably be for the code which runs
> an individual build step (somewhere in `AbstractBuild` IIRC) to check
> the interrupt flag and throw `InterruptedException` at that time.
> Could be verified in a `JenkinsRule`-based test by having a
> `TestBuilder` which mimics the relevant behavior of these libraries.
>
> I doubt this particular issue could apply to Pipeline builds, though
> there might be other ways in which interrupt handling is incorrect
> there as well.
>
--
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/7e5a1511-40b9-4f60-8baa-7668b7405085%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
