9 p.m.
Hi Folks, I'm definitely new to Undertow and super impressed with it.
However the docs are a bit thin in regards to using the RoutingHandler and
doing full async processing. May I ask for a quick check of my approach to
using Undertow and trying not to block anywhere:
https://github.com/bitvector2/microservice2/blob/master/src/main/java/org...
-STEVEl
--
http://www.bitvector.org/
7:40 a.m.
You are blocking the IO thread in each of your handlers.
When each handler is a class, you can do:
if( exchange.isInIoThread()) {
exchange.dispatch(this);
return;
}
but since you are using lambda's, that won't work. In this case, you
might want to just pass a Runnable to exchange.dispatch()
that will put you on a worker pool thread where it is safe to block on
the Await.result call.
an alternate (but lacking the timeout option) method I use is to
leverage the JDK8 CompletableFuture and use .thenAccept / .exceptionally
to return the response when available.
-pete
On 2015-08-29 21:00, Steve Logue wrote:
--
(peter.royal|osi)(a)pobox.com - http://fotap.org/~osi [4]
Links:
------
[1]
https://github.com/bitvector2/microservice2/blob/master/src/main/java/org...
[2] http://www.bitvector.org/
[3] https://lists.jboss.org/mailman/listinfo/undertow-dev
[4] http://fotap.org/~osi
11:08 a.m.
Thanks for looking - how does it look now? This is actually what I had
beforehand at some point. Now it uses a lambda statement to dispatch to
the handler method on a worker thread.
-STEVEl
On Mon, Aug 31, 2015 at 5:40 AM, peter royal <peter.royal(a)pobox.com> wrote:
--
http://www.bitvector.org/
7:28 p.m.
Steve,
At my first look, I felt like you were facing the issue that Peter have
pointed out.
Taking a deeper look into your code, I found out what you have explained on
your last email (line 47 of your source code).
You are right, it seems that you aren't blocking your IO threads.
Just keep in mind that it will always dispatch your request into a Worker
thread. By design, HttpHandler could be nested in a chain of handlers, and
some built in HttpHandlers will dispatch your request into a Worker thread
(as AuthenticationCallHandler, per example). Thus, if you plan to wrap your
requests with such handlers all of your requests will be dispatched into
Worker threads twice per request. To avoid this, you should apply the fix
that Peter have suggested already.
Regards,
Miere
On Mon, Aug 31, 2015 at 1:08 PM Steve Logue <bitvector2(a)gmail.com> wrote:
8:20 p.m.
This is not really correct, as you are setting the exchange into blocking mode and reading
from an input stream.
If you want to go full async there are a few things you need to remove the
'startBlocking()' call. To read the request entity the easiest way before Undertow
1.3 (which is still not quite final) is to use io.undertow.util.StringReadChannelListener.
If you are a recent 1.3.0 beta you can use the new HttpServerExchange.getRequestReceiver()
API.
Here is an example of a handler that uses StringReadChannelListener to simply attach the
post data to the exchange:
https://github.com/undertow-io/undertow.js/blob/master/src/main/java/io/u...
You can then get it in the next handler using the StringReadHandler.DATA attachment key.
Stuart
----- Original Message -----
9:51 p.m.
Btw, Stuart,
Quite interesting this new non-blocking API that was introduced in the
1.3.0 version.
Can you tell me where is a good place to be notified about the 1.3.0's
roadmap and the upcoming new features?
On Mon, Aug 31, 2015 at 10:21 PM Stuart Douglas <sdouglas(a)redhat.com> wrote:
10:06 p.m.
----- Original Message -----
Btw, Stuart,
Quite interesting this new non-blocking API that was introduced in the 1.3.0
version.
It is still possible to do non blocking with the XNIO channel API in prior versions (which
is what StringReadChannelListener uses), this new API is just easier to use.
Can you tell me where is a good place to be notified about the
1.3.0's
roadmap and the upcoming new features?
1.3.0.Final will be released just before Wildfly 10 (which is currently planned for early
October). In general 1.3.x beta releases are quite stable, most of the core functionality
remains unchanged.
Stuart
On Mon, Aug 31, 2015 at 10:21 PM Stuart Douglas <
sdouglas(a)redhat.com >
wrote:
> Stuart
6:36 a.m.
Nice. I did know StringReadChannelListener already, but it is a lil'
verbose to use.
I just took look at StringReaderHandler, it seems quite simple and nice.
Anyway... thank you for the clarification. :]
Regards
On Tue, Sep 1, 2015 at 12:06 AM Stuart Douglas <sdouglas(a)redhat.com> wrote:
3476
days inactive
3478
days old
7 comments
4 participants
participants (4)
-
Miere Teixeira -
peter royal -
Steve Logue -
Stuart Douglas