12:11 p.m.
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)
}
3:44 p.m.
Ok, I think my mail could be reduced to :
Is it possible possible to transfer the HttpServerExchange responsibility to
another thread ?
Regards
Laurent
On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg <laurent(a)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)
}
9:51 p.m.
Hello Laurent,
Your hunch is correct. You never want to block the I/O thread as each thread is shared
between many connections, and a pause prevents them from being processed. It’s totally
reasonable to call dispatch(), which transfers the exchange to the worker pool where you
can wait on a database reply, and in fact this is a normal pattern. The worker pool is
sized to be pretty large as its expected to host lots of waiters. You can of course tweak
this, or dispatch to your own special pool if you like. The big advantage to an async
database call, even with requiring a worker thread, is that you can do other work while
its running if your pattern fits (e.g. parallel db calls, iterative computation, etc).
Alternatively, if the database provides a callback on complete option, you can save
yourself a worker thread and reuse the thread they generate the callback from. At that
callback point you can write your response out to the exchange. Just note, that the
thread policy of an exchange is that only one thread at a time can interact with it. If
you have a use case where the a request bounces back and forth (e.g. a very long stream
containing multiple records that must be written to the database as they com in), then you
will need to coordinate locking around that. Such use-cases though should be weighed
against the simplicity of just blocking in a worker thread.
To answer a second question you have in a comment from your example, startBlocking() just
enables the use of a plain inputstream/outputstream, which can only be done once you have
dispatched and blocking i/o is now ok.
Hope this helps,
-Jason
On Dec 12, 2014, at 3:44 PM, Laurent Bedubourg
<laurent(a)labe.me> wrote:
Ok, I think my mail could be reduced to :
Is it possible possible to transfer the HttpServerExchange responsibility to another
thread ?
Regards
Laurent
On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg <laurent(a)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)
}
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
1:58 a.m.
Thank you very much Jason, it helps me a lot.
One last remark regarding "you can save yourself a worker thread and reuse
the thread they generate the callback from. At that callback point you can
write your response out to the exchange."
When I try to do this, calling x.getResponseSender().send(str) un the
onSuccess callback of the database future, I got an exception
java.lang.IllegalStateException:
UT000004: getResponseChannel() has already been called.
I imagine that the response has already been somehow cleaned up / modified
/ terminated by Undertow when the handler exited (I use
SessionAttachHandler, date() and routing() in my test).
I could not find a way to tell Undertow that I would handle the exchange
and end it manually.
I am using undertow 1.1.1-final maybe this has been fixed since this
version?
Thanks again
Laurent
On Sat Dec 13 2014 at 4:57:33 AM Jason Greene <jason.greene(a)redhat.com>
wrote:
Hello Laurent,
Your hunch is correct. You never want to block the I/O thread as each
thread is shared between many connections, and a pause prevents them from
being processed. It’s totally reasonable to call dispatch(), which
transfers the exchange to the worker pool where you can wait on a database
reply, and in fact this is a normal pattern. The worker pool is sized to be
pretty large as its expected to host lots of waiters. You can of course
tweak this, or dispatch to your own special pool if you like. The big
advantage to an async database call, even with requiring a worker thread,
is that you can do other work while its running if your pattern fits (e.g.
parallel db calls, iterative computation, etc).
Alternatively, if the database provides a callback on complete option, you
can save yourself a worker thread and reuse the thread they generate the
callback from. At that callback point you can write your response out to
the exchange. Just note, that the thread policy of an exchange is that
only one thread at a time can interact with it. If you have a use case
where the a request bounces back and forth (e.g. a very long stream
containing multiple records that must be written to the database as they
com in), then you will need to coordinate locking around that. Such
use-cases though should be weighed against the simplicity of just blocking
in a worker thread.
To answer a second question you have in a comment from your example,
startBlocking() just enables the use of a plain inputstream/outputstream,
which can only be done once you have dispatched and blocking i/o is now ok.
Hope this helps,
-Jason
> On Dec 12, 2014, at 3:44 PM, Laurent Bedubourg <laurent(a)labe.me> wrote:
>
> Ok, I think my mail could be reduced to :
>
> Is it possible possible to transfer the HttpServerExchange
responsibility to another thread ?
>
> Regards
> Laurent
>
>
> On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg <laurent(a)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)
> }
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
4:27 p.m.
You need to call the HttpServerExchange.dispatch() method, which will prevent the exchange
from being ended once the call stack returns.
There is however a thread safety issue here, as you can have your callback being called at
the same time as the call stack is still returning, which means it is possible to have two
threads using the HttpServerExchange, which is not thread safe (in practice this will
*probably* work fine, depending on how your code is written).
The correct way to deal with this is:
HttpServerExchange.dispatch(SameThreadExecutor.INSTANCE, new Runnable() {
public void run() {
//setup callback
}
}
Basically this does two things, calling dispatch means that the exchange will not be ended
when the call stack returns, and dispatching using SameThreadExecutor means that the
runnable will be run immediately after the call stack returns in the IO thread (or
whatever thread is currently active).
If you don't want to use a callback and just want to use await:
HttpServerExchange.dispatch(new Runnable() {
public void run() {
//call await()
}
}
This will dispatch to the worker thread pool, and await() will be called in a worker
thread, although if you use this approach you might as well just use plain JDBC, as you
loose the benefits of non-blocking IO.
Stuart
----- Original Message -----
From: "Laurent Bedubourg" <laurent(a)labe.me>
To: "Jason Greene" <jason.greene(a)redhat.com>
Cc: undertow-dev(a)lists.jboss.org
Sent: Saturday, 13 December, 2014 6:58:51 PM
Subject: Re: [undertow-dev] scala, activate, nio, async jdbc, future, threads
Thank you very much Jason, it helps me a lot.
One last remark regarding " you can save yourself a worker
thread and reuse
the thread they generate the callback from. At that callback point you can
write your response out to the exchange."
When I try to do this, calling x.getResponseSender().send(str) un
the
onSuccess callback of the database future, I got an exception
java.lang.IllegalStateException: UT000004: getResponseChannel() has already
been called.
I imagine that the response has already been somehow cleaned up /
modified /
terminated by Undertow when the handler exited (I use SessionAttachHandler,
date() and routing() in my test).
I could not find a way to tell Undertow that I would handle the
exchange and
end it manually.
I am using undertow 1.1.1-final maybe this has been fixed since this
version?
Thanks again
Laurent
On Sat Dec 13 2014 at 4:57:33 AM Jason Greene <
jason.greene(a)redhat.com >
wrote:
> Hello Laurent,
> Your hunch is correct. You never want to block the I/O thread as
each
> thread
> is shared between many connections, and a pause prevents them from being
> processed. It’s totally reasonable to call dispatch(), which transfers the
> exchange to the worker pool where you can wait on a database reply, and in
> fact this is a normal pattern. The worker pool is sized to be pretty large
> as its expected to host lots of waiters. You can of course tweak this, or
> dispatch to your own special pool if you like. The big advantage to an
> async
> database call, even with requiring a worker thread, is that you can do
> other
> work while its running if your pattern fits (e.g. parallel db calls,
> iterative computation, etc).
> Alternatively, if the database provides a callback on complete
option, you
> can save yourself a worker thread and reuse the thread they generate the
> callback from. At that callback point you can write your response out to
> the
> exchange. Just note, that the thread policy of an exchange is that only one
> thread at a time can interact with it. If you have a use case where the a
> request bounces back and forth (e.g. a very long stream containing multiple
> records that must be written to the database as they com in), then you will
> need to coordinate locking around that. Such use-cases though should be
> weighed against the simplicity of just blocking in a worker thread.
> To answer a second question you have in a comment from your
example,
> startBlocking() just enables the use of a plain inputstream/outputstream,
> which can only be done once you have dispatched and blocking i/o is now ok.
> Hope this helps,
> -Jason
> > > On Dec 12, 2014, at 3:44 PM, Laurent Bedubourg < laurent(a)labe.me >
wrote:
>
> > >
>
> > > Ok, I think my mail could be reduced to :
>
> > >
>
> > > Is it possible possible to transfer the HttpServerExchange responsibility
> > > to another thread ?
>
> > >
>
> > > Regards
>
> > Laurent
>
> > >
>
> > >
>
> > > On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg < laurent(a)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)
>
> > > }
>
> > >
>
> > > ______________________________ _________________
>
> > > undertow-dev mailing list
>
> > > undertow-dev(a)lists.jboss.org
>
> > > https://lists.jboss.org/ mailman/listinfo/undertow-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> ______________________________ _________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/ mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
12:56 a.m.
Thank you Stuart, I will try this ASAP.
Best regards
Laurent
On Sun, 14 Dec 2014 23:28 Stuart Douglas <sdouglas(a)redhat.com> wrote:
You need to call the HttpServerExchange.dispatch() method, which
will
prevent the exchange from being ended once the call stack returns.
There is however a thread safety issue here, as you can have your callback
being called at the same time as the call stack is still returning, which
means it is possible to have two threads using the HttpServerExchange,
which is not thread safe (in practice this will *probably* work fine,
depending on how your code is written).
The correct way to deal with this is:
HttpServerExchange.dispatch(SameThreadExecutor.INSTANCE, new Runnable() {
public void run() {
//setup callback
}
}
Basically this does two things, calling dispatch means that the exchange
will not be ended when the call stack returns, and dispatching using
SameThreadExecutor means that the runnable will be run immediately after
the call stack returns in the IO thread (or whatever thread is currently
active).
If you don't want to use a callback and just want to use await:
HttpServerExchange.dispatch(new Runnable() {
public void run() {
//call await()
}
}
This will dispatch to the worker thread pool, and await() will be called
in a worker thread, although if you use this approach you might as well
just use plain JDBC, as you loose the benefits of non-blocking IO.
Stuart
------------------------------
*From: *"Laurent Bedubourg" <laurent(a)labe.me>
*To: *"Jason Greene" <jason.greene(a)redhat.com>
*Cc: *undertow-dev(a)lists.jboss.org
*Sent: *Saturday, 13 December, 2014 6:58:51 PM
*Subject: *Re: [undertow-dev] scala, activate, nio, async jdbc, future,
threads
Thank you very much Jason, it helps me a lot.
One last remark regarding "you can save yourself a worker thread and
reuse the thread they generate the callback from. At that callback point
you can write your response out to the exchange."
When I try to do this, calling x.getResponseSender().send(str) un the
onSuccess callback of the database future, I got an exception
java.lang.IllegalStateException:
UT000004: getResponseChannel() has already been called.
I imagine that the response has already been somehow cleaned up / modified
/ terminated by Undertow when the handler exited (I use
SessionAttachHandler, date() and routing() in my test).
I could not find a way to tell Undertow that I would handle the exchange
and end it manually.
I am using undertow 1.1.1-final maybe this has been fixed since this
version?
Thanks again
Laurent
On Sat Dec 13 2014 at 4:57:33 AM Jason Greene <jason.greene(a)redhat.com>
wrote:
> Hello Laurent,
>
> Your hunch is correct. You never want to block the I/O thread as each
> thread is shared between many connections, and a pause prevents them from
> being processed. It’s totally reasonable to call dispatch(), which
> transfers the exchange to the worker pool where you can wait on a database
> reply, and in fact this is a normal pattern. The worker pool is sized to be
> pretty large as its expected to host lots of waiters. You can of course
> tweak this, or dispatch to your own special pool if you like. The big
> advantage to an async database call, even with requiring a worker thread,
> is that you can do other work while its running if your pattern fits (e.g.
> parallel db calls, iterative computation, etc).
>
> Alternatively, if the database provides a callback on complete option,
> you can save yourself a worker thread and reuse the thread they generate
> the callback from. At that callback point you can write your response out
> to the exchange. Just note, that the thread policy of an exchange is that
> only one thread at a time can interact with it. If you have a use case
> where the a request bounces back and forth (e.g. a very long stream
> containing multiple records that must be written to the database as they
> com in), then you will need to coordinate locking around that. Such
> use-cases though should be weighed against the simplicity of just blocking
> in a worker thread.
>
> To answer a second question you have in a comment from your example,
> startBlocking() just enables the use of a plain inputstream/outputstream,
> which can only be done once you have dispatched and blocking i/o is now ok.
>
> Hope this helps,
>
> -Jason
>
> > On Dec 12, 2014, at 3:44 PM, Laurent Bedubourg <laurent(a)labe.me> wrote:
> >
> > Ok, I think my mail could be reduced to :
> >
> > Is it possible possible to transfer the HttpServerExchange
> responsibility to another thread ?
> >
> > Regards
> > Laurent
> >
> >
> > On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg <laurent(a)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)
> > }
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
5:40 a.m.
Works like a charm, thanks again.
On Mon Dec 15 2014 at 7:56:49 AM Laurent Bedubourg <laurent(a)labe.me> wrote:
Thank you Stuart, I will try this ASAP.
Best regards
Laurent
On Sun, 14 Dec 2014 23:28 Stuart Douglas <sdouglas(a)redhat.com> wrote:
> You need to call the HttpServerExchange.dispatch() method, which will
> prevent the exchange from being ended once the call stack returns.
>
> There is however a thread safety issue here, as you can have your
> callback being called at the same time as the call stack is still
> returning, which means it is possible to have two threads using the
> HttpServerExchange, which is not thread safe (in practice this will
> *probably* work fine, depending on how your code is written).
>
> The correct way to deal with this is:
>
> HttpServerExchange.dispatch(SameThreadExecutor.INSTANCE, new Runnable() {
> public void run() {
> //setup callback
> }
> }
>
> Basically this does two things, calling dispatch means that the exchange
> will not be ended when the call stack returns, and dispatching using
> SameThreadExecutor means that the runnable will be run immediately after
> the call stack returns in the IO thread (or whatever thread is currently
> active).
>
> If you don't want to use a callback and just want to use await:
>
> HttpServerExchange.dispatch(new Runnable() {
> public void run() {
> //call await()
> }
> }
>
> This will dispatch to the worker thread pool, and await() will be called
> in a worker thread, although if you use this approach you might as well
> just use plain JDBC, as you loose the benefits of non-blocking IO.
>
> Stuart
>
> ------------------------------
>
> *From: *"Laurent Bedubourg" <laurent(a)labe.me>
> *To: *"Jason Greene" <jason.greene(a)redhat.com>
> *Cc: *undertow-dev(a)lists.jboss.org
> *Sent: *Saturday, 13 December, 2014 6:58:51 PM
> *Subject: *Re: [undertow-dev] scala, activate, nio, async jdbc, future,
> threads
>
>
>
> Thank you very much Jason, it helps me a lot.
>
> One last remark regarding "you can save yourself a worker thread and
> reuse the thread they generate the callback from. At that callback point
> you can write your response out to the exchange."
>
> When I try to do this, calling x.getResponseSender().send(str) un the
> onSuccess callback of the database future, I got an exception
java.lang.IllegalStateException:
> UT000004: getResponseChannel() has already been called.
>
> I imagine that the response has already been somehow cleaned up /
> modified / terminated by Undertow when the handler exited (I use
> SessionAttachHandler, date() and routing() in my test).
>
> I could not find a way to tell Undertow that I would handle the exchange
> and end it manually.
>
> I am using undertow 1.1.1-final maybe this has been fixed since this
> version?
>
> Thanks again
>
> Laurent
>
>
>
> On Sat Dec 13 2014 at 4:57:33 AM Jason Greene <jason.greene(a)redhat.com>
> wrote:
>
>> Hello Laurent,
>>
>> Your hunch is correct. You never want to block the I/O thread as each
>> thread is shared between many connections, and a pause prevents them from
>> being processed. It’s totally reasonable to call dispatch(), which
>> transfers the exchange to the worker pool where you can wait on a database
>> reply, and in fact this is a normal pattern. The worker pool is sized to be
>> pretty large as its expected to host lots of waiters. You can of course
>> tweak this, or dispatch to your own special pool if you like. The big
>> advantage to an async database call, even with requiring a worker thread,
>> is that you can do other work while its running if your pattern fits (e.g.
>> parallel db calls, iterative computation, etc).
>>
>> Alternatively, if the database provides a callback on complete option,
>> you can save yourself a worker thread and reuse the thread they generate
>> the callback from. At that callback point you can write your response out
>> to the exchange. Just note, that the thread policy of an exchange is that
>> only one thread at a time can interact with it. If you have a use case
>> where the a request bounces back and forth (e.g. a very long stream
>> containing multiple records that must be written to the database as they
>> com in), then you will need to coordinate locking around that. Such
>> use-cases though should be weighed against the simplicity of just blocking
>> in a worker thread.
>>
>> To answer a second question you have in a comment from your example,
>> startBlocking() just enables the use of a plain inputstream/outputstream,
>> which can only be done once you have dispatched and blocking i/o is now ok.
>>
>> Hope this helps,
>>
>> -Jason
>>
>> > On Dec 12, 2014, at 3:44 PM, Laurent Bedubourg <laurent(a)labe.me>
>> wrote:
>> >
>> > Ok, I think my mail could be reduced to :
>> >
>> > Is it possible possible to transfer the HttpServerExchange
>> responsibility to another thread ?
>> >
>> > Regards
>> > Laurent
>> >
>> >
>> > On Fri Dec 12 2014 at 7:11:01 PM Laurent Bedubourg <laurent(a)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)
>> > }
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
3435
days inactive
3438
days old
6 comments
3 participants
participants (3)
-
Jason Greene -
Laurent Bedubourg -
Stuart Douglas