sbt-play-gulp icon indicating copy to clipboard operation
sbt-play-gulp copied to clipboard

devAssetHandler Issue with `HttpEntity.Streamed`

Open qwwqwwq opened this issue 7 years ago • 0 comments

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!

qwwqwwq avatar Mar 06 '17 19:03 qwwqwwq