ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jaikiran <>
Subject [GitHub] ant pull request #52: [master] Fix BZ-58451 BZ-58833
Date Sat, 16 Dec 2017 10:18:31 GMT
GitHub user jaikiran opened a pull request:

    [master] Fix BZ-58451 BZ-58833

    The commit here fixes the issues reported in:
    The `PumpStreamHandler` and the `StreamPumper` work together for redirecting the streams
(reading from inputstream and writing to a outputstream). When the `StreamPumper` is asked
to stop, it stops reading from the input stream and goes on to finish any (non-blocking) reads
and finally a (potentially blocking) flush of whatever it has read so far. The `PumpStreamHandler`,
which initiates that `stop` is a bit too impatient (mainly because of its inability to know
what's going on in `StreamPumper` after the `stop` was invoked on it) and starts interrupting
the `StreamPumper`'s thread very soon (as early as 200 milli seconds after stop). This triggers
a bunch of issues in `StreamPumper`, which either is in the middle of finishing the non-blocking
reads or in the middle of actually flushing out whatever it's held on to and ultimately leads
to a non-clean stop and thus corrupting/truncating the output stream as noted in those issues.
    The commit here introduces a way, through the `PostStopHandle`, for `PumpStreamHandler`
to be aware that upon `stop` the `StreamPumper` has respected the call to `stop` and is doing
certain post-stop finishing acts before actually being considered `finished`. The `PumpStreamHandler`
then allows a bit of time for the post-stop tasks to finish before actually trying to kill
off the `StreamPumper` using thread interrupts, if the `StreamPumper` didn't finish after
that grace period.
    The commit here intentionally does _not_ introduce a configurable "grace period" for the
post-stop activities and instead using a hard coded (maximum) 2 seconds for the following
    * The 2 seconds is the _maxium_ amount of time to let the post-stop to complete, so it's
not always going to wait that long
    * The cleaning up gracefully is an internal implementation detail and doesn't have to
end up being configured by the user.
    * Finally, the `PumpStreamHandler` anyway falls back to the thread interrupts if the post-stop
(flush() etc...) doesn't complete in those 2 seconds. So from a end user point of view, there
isn't really any behaviour change, except that we now give the `StreamPumper` a chance to
gracefully stop.
    This PR is against master branch. If this is approved I'll backport it to 1.9.x branch

You can merge this pull request into a Git repository by running:

    $ git pull bz-58451-master

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #52
commit 3bcdac90581cb78e4a49b0b7fe6b01657a6436f1
Author: Jaikiran Pai <>
Date:   2017-12-16T09:48:30Z

    BZ-58451 BZ-58833 Give StreamPumper a chance to finish cleanly before interrupting its
thread, to prevent truncated output



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message