Hello,
The good news is that it more or less works.
My main concern is that the database system create threads using scala futures and that I am forced to "Await" for the result of my Futures to send the result to the HttpServerExchange.
I am forced to dispath() the request because Await locks the current thread and I shouldn't lock the IO thread from my Handler, should I?
It made me wondering : is is really a good idea to use futures + Await with undertow and more generaly nio?
If the thread pool is limited and I lock threads, even if the database driver is async and uses nio, am I bitting my own leg?
Thanks for any input you can give me and sorry if it's too scala related :)
Regards
Laurent
PS: Here's the handleRequest I am using to test this, any comment or help welcome too since I am discovering the API.
def handleRequest(x:io.undertow.server.HttpServerExchange){
if (x.isInIoThread()){
x.dispatch(this)
return
}
// useful or not? no change
// x.startBlocking()
// Ok, we are in worker thread we can work a little with database
// val f = asyncTransactionalChain { implicit context =>
// for (
// a <- asyncTransactional { new AMember("aaa") };
// b <- asyncById[AMember](
a.id)
// ) yield b
// }
// Simulate database work with just a future
val f = future {
Some(1)
}(scala.concurrent.ExecutionContext.Implicits.global)
// send string to xchange
def sendReply(str:String){
x.getResponseHeaders().put(io.undertow.util.Headers.CONTENT_TYPE, "text/plain")
x.getResponseSender().send(str)
// x.endExchange()
}
// // this fails
// f.onSuccess {
// case Some(result) => sendReply(result.toString)
// }(scala.concurrent.ExecutionContext.Implicits.global)
// // this works
val result = Await.result(f, Duration(1000, MILLISECONDS))
sendReply(result.toString)
}