When we tried invoking the sbt-less plugin on the Activator project, about 50 LESS files were attempted to be processed. The build failed with an actor ask timeout.
After analysing stack dumps and profiling via YourKit I discovered that both ends of the PipedInput/OutputStreams appeared to be waiting for each other. It turns out that the PipedInput/OutputStream classes are unsuitable for situations where thread pools are used and the thread that is used to write output is unpredictable.
I have now eliminated the JDK PipedInput/OutputStream usage by replacing with enhanced Source and Sink types along with a new SourceStream and a SinkStream type.
When we tried invoking the sbt-less plugin on the Activator project, about 50 LESS files were attempted to be processed. The build failed with an actor ask timeout.
After analysing stack dumps and profiling via YourKit I discovered that both ends of the PipedInput/OutputStreams appeared to be waiting for each other. It turns out that the PipedInput/OutputStream classes are unsuitable for situations where thread pools are used and the thread that is used to write output is unpredictable.
I have now eliminated the JDK PipedInput/OutputStream usage by replacing with enhanced Source and Sink types along with a new SourceStream and a SinkStream type.