DelayedOutputStream and Ok.chunked performance

[CassOnMars]

In my fork I have already removed DelayedOutputStream and substituted it with just a ByteArrayOutputStream, so that I could shrink the handle method in CxfController down to

val delayedOutput = new ByteArrayOutputStream
val replyPromise: Promise[Message] = Promise.apply()
dispatchMessage(extractMessage, delayedOutput, replyPromise)

replyPromise.future.map { outMessage =>
  Ok(delayedOutput.toByteArray) withHeaders(
    Message.CONTENT_TYPE -> outMessage.get(Message.CONTENT_TYPE).asInstanceOf[String]
  )
}

So far, I haven't found any problems in doing so, and the response time improved by nearly 200ms in my test environment. I'm curious if there was a reason in using the DelayedOutputStream rather than the direct dump of the byte array? I would gladly set up a pull request if this change is acceptable.

[kustra]

Using DelayedOutputStream is supposed to avoid storing the whole response in memory before returning it to the client, assuming that Apache CXF (or Play) doesn't store the whole response in memory either.
This could mean a difference with large response bodies.
(I haven't tested it in practice so it might not work as intended just yet.)

I understand it's not needed for everyone, but I wouldn't just remove it. If you were to abstract this logic out of CxfHandler and make it changeable by the programmer, I would be glad to accept a pull request. I guess some pluggable "CXF Message to Play Result" converter trait and its two implementations (Delayed and ByteArray) could do the trick.

[CassOnMars]

I'll look further into how the DelayedOutputStream is behaving, and reformulate the pull request accordingly.

Thank you for your comments.