On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg <laurent@labe.me> wrote:

Hello,

I am evaluating Undertow and trying to fit an async database (with scala, Activate and https://github.com/mauricio/postgresql-async which use netty and nio).

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)
}