The issue is as follows:

First JNLP NIO creates a Channel A.
Then AbstractMavenProcessFactory.newProcess creates a new Channel B by invoking the following:

            Channel ch = Channels.forProcess("Channel to Maven " + Arrays.toString(cmds),
                    Computer.threadPoolForRemoting, new BufferedInputStream(con.in), new BufferedOutputStream(con.out),
                    listener.getLogger(), proc);

The problem is, if Channel A abruptly terminates, Channel B will be stuck in all currently pending read operations (see stack traces above). The only way to terminate those read operations is to interrupt the threads that are blocked in said reads. The only way this can be achieved now is through a manual job abort (or, presumably, a Build Timeout plugin).

There is no easy or short fix for this without a major remoting rewrite. The problem is two-fold:

  1. Chaining channels requires upstream channels to track downstream ones. Given the current APIs and that channels are dependent on other channels via arbitrary I/O streams that are neither channel- nor dependency-aware altogether, it is virtually impossible.
  2. Even if the first hurdle can be overcome, all threads blocked in IOPs have to be tracked to be interruptable asynchrnously with implementation complexity on par with Java's InterruptibleChannel.
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/d/optout.

Reply via email to