sbt-play-gulp
sbt-play-gulp copied to clipboard
devAssetHandler Issue with `HttpEntity.Streamed`
With the following versions: scala: 2.11.8 sbt-play-gulp: 0.1.5 play framework: 2.5.12
I am seeing this stacktrace when processing a GET request on gulp assets:
java.lang.IllegalStateException: Promise already completed.
at scala.concurrent.Promise$class.complete(Promise.scala:55)
at scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:153)
at scala.concurrent.Promise$class.failure(Promise.scala:104)
at scala.concurrent.impl.Promise$DefaultPromise.failure(Promise.scala:153)
at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:257)
at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:251)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55)
at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:91)
at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91)
I have read through an issue posted on the akka project that produces a similar stacktrace: https://github.com/akka/akka/issues/19981
My conclusion is that the use of HttpEntity.Streamed
as opposed to HttpEntity.Strict
might be the culprit.
Assuming that the performance of the devAssetHandler is not a primary concern, would it be reasonable to switch it to use HttpEntity.Strict
? What was the original motivation for using HttpEntity.Streamed
, and can anyone more informed than me tell if there is some issue with HOW HttpEntity.Streamed
is being used here:
https://github.com/mmizutani/sbt-play-gulp/blob/babc74a79468b7f1ffc2c19a18a293d145ebd00b/play-gulp/app/com/github/mmizutani/playgulp/GulpAssets.scala#L91
Thanks!