From bburke at redhat.com  Mon Dec  1 10:13:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 10:13:48 -0500
Subject: [undertow-dev] req.authenticate() problems 1.1.0
In-Reply-To: <88575048.4255911.1416948115410.JavaMail.zimbra@redhat.com>
References: <5474AEB1.8030405@redhat.com>
	<1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com>
	<88575048.4255911.1416948115410.JavaMail.zimbra@redhat.com>
Message-ID: <547C85AC.3050606@redhat.com>

1.1.1 or 1.2.x release incoming?  We're doing a keycloak release with 
the proxy this week, just wondering if I should delay if undertow is 
incoming so I can upgrade the proxy distro.

On 11/25/2014 3:41 PM, Stuart Douglas wrote:
> This should be fixed upstream, I will do a 1.1.1 release shortly, so if you discover any other issues let me know and I will try and get them into this release.
>
> Stuart
>
> ----- Original Message -----
>> From: "Stuart Douglas" <sdouglas at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Wednesday, 26 November, 2014 6:19:41 AM
>> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
>>
>> Is the code up on Github anywhere? If so I can take a look.
>>
>> Stuart
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: undertow-dev at lists.jboss.org
>>> Sent: Wednesday, 26 November, 2014 3:30:41 AM
>>> Subject: [undertow-dev] req.authenticate() problems 1.1.0
>>>
>>> When upgrading from Undertow 1.0.15 to 1.1.0 our
>>> HttpServleRequest.authenticate() unit test is failing.  An exception is
>>> being thrown in HttpServletRequestImpl.authenticate() line 416.
>>>
>>> Our auth mechanism is being called correctly.  It sets the status code
>>> (302) and the Location header within a challenge object.  It looks like
>>> exchange.isResponseStarted() is returning false even though my challenge
>>> object is setting up the resposne correctly.  Am I supposed to call
>>> exchange.endExchange() or something within my Challenge object?  I tried
>>> doing that, but Undertow is now spitting out exception messages:
>>>
>>> java.lang.IllegalStateException: UT000002: The response has already been
>>> started
>>> 	at
>>> io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109)
>>> 	at
>>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
>>> 	at
>>> io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404)
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Mon Dec  1 19:18:39 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 1 Dec 2014 19:18:39 -0500 (EST)
Subject: [undertow-dev] req.authenticate() problems 1.1.0
In-Reply-To: <547C85AC.3050606@redhat.com>
References: <5474AEB1.8030405@redhat.com>
	<1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com>
	<88575048.4255911.1416948115410.JavaMail.zimbra@redhat.com>
	<547C85AC.3050606@redhat.com>
Message-ID: <416836001.6544247.1417479519254.JavaMail.zimbra@redhat.com>

I have cut 1.1.1.Final

Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Tuesday, 2 December, 2014 2:13:48 AM
> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
> 
> 1.1.1 or 1.2.x release incoming?  We're doing a keycloak release with
> the proxy this week, just wondering if I should delay if undertow is
> incoming so I can upgrade the proxy distro.
> 
> On 11/25/2014 3:41 PM, Stuart Douglas wrote:
> > This should be fixed upstream, I will do a 1.1.1 release shortly, so if you
> > discover any other issues let me know and I will try and get them into
> > this release.
> >
> > Stuart
> >
> > ----- Original Message -----
> >> From: "Stuart Douglas" <sdouglas at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: undertow-dev at lists.jboss.org
> >> Sent: Wednesday, 26 November, 2014 6:19:41 AM
> >> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
> >>
> >> Is the code up on Github anywhere? If so I can take a look.
> >>
> >> Stuart
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: undertow-dev at lists.jboss.org
> >>> Sent: Wednesday, 26 November, 2014 3:30:41 AM
> >>> Subject: [undertow-dev] req.authenticate() problems 1.1.0
> >>>
> >>> When upgrading from Undertow 1.0.15 to 1.1.0 our
> >>> HttpServleRequest.authenticate() unit test is failing.  An exception is
> >>> being thrown in HttpServletRequestImpl.authenticate() line 416.
> >>>
> >>> Our auth mechanism is being called correctly.  It sets the status code
> >>> (302) and the Location header within a challenge object.  It looks like
> >>> exchange.isResponseStarted() is returning false even though my challenge
> >>> object is setting up the resposne correctly.  Am I supposed to call
> >>> exchange.endExchange() or something within my Challenge object?  I tried
> >>> doing that, but Undertow is now spitting out exception messages:
> >>>
> >>> java.lang.IllegalStateException: UT000002: The response has already been
> >>> started
> >>> 	at
> >>> io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109)
> >>> 	at
> >>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
> >>> 	at
> >>> io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404)
> >>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From pbetkier at gmail.com  Wed Dec  3 17:12:25 2014
From: pbetkier at gmail.com (Piotr Betkier)
Date: Wed, 03 Dec 2014 22:12:25 +0000
Subject: [undertow-dev] Unexpected RequestLimitingHandler behavior after
	queue gets full
Message-ID: <CALmv1y+owvXZWx8M8Zc5kdDzJVhqzha3QTNe3=fddzW1rZZpHA@mail.gmail.com>

Hello,

I wanted to introduce a constraint on the number of requests my server
tries to handle at a time and played around with RequestLimitingHandler a
little bit. However, I observed unexpected behavior once RequestLimit's
queue gets full.

I've created a RequestLimitingHandler with both maximumConcurrentRequests
and queueSize set to 1 and nextHandler that responds after a 3 second
sleep. This is what I observed:

When I sent 2 concurrent requests with a curl, I got the first response
after 3 seconds and the second one after 6 - just as expected, the second
request got queued.

When I sent 3 concurrent requests, I got two correct responses and one 513
- just as expected, my third request couldn't fit into the queue so a
failure handler got called.

Now it got tricky - this made RequestLimit enter an invalid state, where
its "state" field got decremented below the value that represents 0 current
requests. Now "state & MASK_CURRENT" gives 2147483647 instead of 0, so the
next time I make a single request, RequestLimit thinks there are 2147483647
requests in the system currently and queues my request instead of handling
it. Then I make yet another request and now the queue is full, so 513 error
is generated instantly which in turn makes RequestLimit poll my first
pending request from the queue and dispatch it for handling. RequestLimit
got corrupted and is unusable from now on.

I hope I explained my observations clearly. Is there something wrong in my
setup, my understanding of Undertow or it's a bug? This is my code snippet,
tested with undertow 1.1.0.Final and 1.2.0.Beta5:

import io.undertow.Undertow;
import io.undertow.server.HttpHandler;
import io.undertow.server.HttpServerExchange;
import io.undertow.server.handlers.RequestLimitingHandler;
import io.undertow.util.Headers;

public class Main {

    public static void main(String[] args) {
        Undertow server = Undertow.builder()
                .addHttpListener(8080, "localhost")
                .setHandler(new RequestLimitingHandler(1, 1, handler()))
                .build();

        server.start();
    }

    private static HttpHandler handler() {
        return new HttpHandler() {
            @Override
            public void handleRequest(final HttpServerExchange exchange)
throws Exception {
                Thread.sleep(3000);
                exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
"text/plain");
                exchange.getResponseSender().send("Hello World");
            }
        };
    }

}


Cheers,
Piotr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141203/7dacd11a/attachment-0001.html 

From sdouglas at redhat.com  Wed Dec  3 21:06:04 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 3 Dec 2014 21:06:04 -0500 (EST)
Subject: [undertow-dev] Unexpected RequestLimitingHandler behavior
	after	queue gets full
In-Reply-To: <CALmv1y+owvXZWx8M8Zc5kdDzJVhqzha3QTNe3=fddzW1rZZpHA@mail.gmail.com>
References: <CALmv1y+owvXZWx8M8Zc5kdDzJVhqzha3QTNe3=fddzW1rZZpHA@mail.gmail.com>
Message-ID: <336074498.7729251.1417658764769.JavaMail.zimbra@redhat.com>

I created a JIRA:

https://issues.jboss.org/browse/UNDERTOW-349

Fix is upstream, will be in release of 1.1.2.Final and 1.2.0.Beta7. 

Stuart

----- Original Message -----
> From: "Piotr Betkier" <pbetkier at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 4 December, 2014 9:12:25 AM
> Subject: [undertow-dev] Unexpected RequestLimitingHandler behavior after	queue gets full
> 
> Hello,
> 
> I wanted to introduce a constraint on the number of requests my server tries
> to handle at a time and played around with RequestLimitingHandler a little
> bit. However, I observed unexpected behavior once RequestLimit's queue gets
> full.
> 
> I've created a RequestLimitingHandler with both maximumConcurrentRequests and
> queueSize set to 1 and nextHandler that responds after a 3 second sleep.
> This is what I observed:
> 
> When I sent 2 concurrent requests with a curl, I got the first response after
> 3 seconds and the second one after 6 - just as expected, the second request
> got queued.
> 
> When I sent 3 concurrent requests, I got two correct responses and one 513 -
> just as expected, my third request couldn't fit into the queue so a failure
> handler got called.
> 
> Now it got tricky - this made RequestLimit enter an invalid state, where its
> "state" field got decremented below the value that represents 0 current
> requests. Now "state & MASK_CURRENT" gives 2147483647 instead of 0, so the
> next time I make a single request, RequestLimit thinks there are 2147483647
> requests in the system currently and queues my request instead of handling
> it. Then I make yet another request and now the queue is full, so 513 error
> is generated instantly which in turn makes RequestLimit poll my first
> pending request from the queue and dispatch it for handling. RequestLimit
> got corrupted and is unusable from now on.
> 
> I hope I explained my observations clearly. Is there something wrong in my
> setup, my understanding of Undertow or it's a bug? This is my code snippet,
> tested with undertow 1.1.0.Final and 1.2.0.Beta5:
> 
> import io.undertow.Undertow;
> import io.undertow.server.HttpHandler;
> import io.undertow.server.HttpServerExchange;
> import io.undertow.server.handlers.RequestLimitingHandler;
> import io.undertow.util.Headers;
> 
> public class Main {
> 
> public static void main(String[] args) {
> Undertow server = Undertow.builder()
> .addHttpListener(8080, "localhost")
> .setHandler(new RequestLimitingHandler(1, 1, handler()))
> .build();
> 
> server.start();
> }
> 
> private static HttpHandler handler() {
> return new HttpHandler() {
> @Override
> public void handleRequest(final HttpServerExchange exchange) throws Exception
> {
> Thread.sleep(3000);
> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> exchange.getResponseSender().send("Hello World");
> }
> };
> }
> 
> }
> 
> 
> Cheers,
> Piotr
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From pbetkier at gmail.com  Thu Dec  4 02:48:25 2014
From: pbetkier at gmail.com (Piotr Betkier)
Date: Thu, 04 Dec 2014 07:48:25 +0000
Subject: [undertow-dev] Unexpected RequestLimitingHandler behavior after
 queue gets full
References: <CALmv1y+owvXZWx8M8Zc5kdDzJVhqzha3QTNe3=fddzW1rZZpHA@mail.gmail.com>
	<336074498.7729251.1417658764769.JavaMail.zimbra@redhat.com>
Message-ID: <CALmv1yLOH9e60cNKLFnB1Rn6PSW4qA4gEAOBghEVZ5cX=k2aPw@mail.gmail.com>

Awesome, thanks!

Piotr

On Thu Dec 04 2014 at 3:06:07 AM Stuart Douglas <sdouglas at redhat.com> wrote:

> I created a JIRA:
>
> https://issues.jboss.org/browse/UNDERTOW-349
>
> Fix is upstream, will be in release of 1.1.2.Final and 1.2.0.Beta7.
>
> Stuart
>
> ----- Original Message -----
> > From: "Piotr Betkier" <pbetkier at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Thursday, 4 December, 2014 9:12:25 AM
> > Subject: [undertow-dev] Unexpected RequestLimitingHandler behavior
> after      queue gets full
> >
> > Hello,
> >
> > I wanted to introduce a constraint on the number of requests my server
> tries
> > to handle at a time and played around with RequestLimitingHandler a
> little
> > bit. However, I observed unexpected behavior once RequestLimit's queue
> gets
> > full.
> >
> > I've created a RequestLimitingHandler with both
> maximumConcurrentRequests and
> > queueSize set to 1 and nextHandler that responds after a 3 second sleep.
> > This is what I observed:
> >
> > When I sent 2 concurrent requests with a curl, I got the first response
> after
> > 3 seconds and the second one after 6 - just as expected, the second
> request
> > got queued.
> >
> > When I sent 3 concurrent requests, I got two correct responses and one
> 513 -
> > just as expected, my third request couldn't fit into the queue so a
> failure
> > handler got called.
> >
> > Now it got tricky - this made RequestLimit enter an invalid state, where
> its
> > "state" field got decremented below the value that represents 0 current
> > requests. Now "state & MASK_CURRENT" gives 2147483647 instead of 0, so
> the
> > next time I make a single request, RequestLimit thinks there are
> 2147483647
> > requests in the system currently and queues my request instead of
> handling
> > it. Then I make yet another request and now the queue is full, so 513
> error
> > is generated instantly which in turn makes RequestLimit poll my first
> > pending request from the queue and dispatch it for handling. RequestLimit
> > got corrupted and is unusable from now on.
> >
> > I hope I explained my observations clearly. Is there something wrong in
> my
> > setup, my understanding of Undertow or it's a bug? This is my code
> snippet,
> > tested with undertow 1.1.0.Final and 1.2.0.Beta5:
> >
> > import io.undertow.Undertow;
> > import io.undertow.server.HttpHandler;
> > import io.undertow.server.HttpServerExchange;
> > import io.undertow.server.handlers.RequestLimitingHandler;
> > import io.undertow.util.Headers;
> >
> > public class Main {
> >
> > public static void main(String[] args) {
> > Undertow server = Undertow.builder()
> > .addHttpListener(8080, "localhost")
> > .setHandler(new RequestLimitingHandler(1, 1, handler()))
> > .build();
> >
> > server.start();
> > }
> >
> > private static HttpHandler handler() {
> > return new HttpHandler() {
> > @Override
> > public void handleRequest(final HttpServerExchange exchange) throws
> Exception
> > {
> > Thread.sleep(3000);
> > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> > exchange.getResponseSender().send("Hello World");
> > }
> > };
> > }
> >
> > }
> >
> >
> > Cheers,
> > Piotr
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141204/bcac4e7c/attachment.html 

From ungarida at gmail.com  Fri Dec  5 12:08:18 2014
From: ungarida at gmail.com (Davide Ungari)
Date: Fri, 5 Dec 2014 18:08:18 +0100
Subject: [undertow-dev] HTTP/2 REST API
Message-ID: <CA+TL3n3N+FirLFqtY6coiuQsWw7tL0oTEg21tDpXM2uJAR9SKA@mail.gmail.com>

Hi,
I would like to understand how to make a REST API with RestEasy and
Undertow be served with HTTP/2 or SPDY. How have I to configure Undertow?

I have a frontend application running on Undertow calling this REST API on
another Undertow instance. How can I configure both to use HTTP/2?

Does all this "optimization" make sense?

Thanks everybody

--
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141205/fd64507a/attachment.html 

From bburke at redhat.com  Fri Dec  5 16:48:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 16:48:20 -0500
Subject: [undertow-dev] exchange.isInIoThread()
Message-ID: <54822824.3000205@redhat.com>

I'm using the Undertow ProxyHandler, should I be executing the 
ProxyHandler in a separate thread?  What I"m running into right now is 
that I'm making a nested HTTP call within a Servlet request ( GET 
http://proxy.com which invokes a call to http://proxy.com/test) and the 
2nd call isn't getting through.

The nested call never gets passed AuthenticationCallHandler line 46.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Dec  5 18:07:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 18:07:19 -0500
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <54822824.3000205@redhat.com>
References: <54822824.3000205@redhat.com>
Message-ID: <54823AA7.5060208@redhat.com>

I removed the isInIoThread() check in a fork of 
AuthenticationCallHandler.  Hopefully this is correct.

On 12/5/2014 4:48 PM, Bill Burke wrote:
> I'm using the Undertow ProxyHandler, should I be executing the
> ProxyHandler in a separate thread?  What I"m running into right now is
> that I'm making a nested HTTP call within a Servlet request ( GET
> http://proxy.com which invokes a call to http://proxy.com/test) and the
> 2nd call isn't getting through.
>
> The nested call never gets passed AuthenticationCallHandler line 46.
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Fri Dec  5 21:07:13 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sat, 06 Dec 2014 13:07:13 +1100
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <54823AA7.5060208@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
Message-ID: <548264D1.4040904@redhat.com>

The reason why that check is there is that the authenticate call may 
involve blocking operations, which you should not do in an IO thread.

Can I have a look at the code? The proxy handler will only execute in 
the IO thread, and is not really servlet aware, so I have not really 
though about how they will work together (you may need to call 
startAsync() on the servlet request).

The reason for this design is that the proxy handler connects to the 
target server using the same IO thread as the original request. This 
means that there is only ever one thread involved in the proxy process, 
and we don't need to use any kind of synchronization.

If the request is running in a worker thread it is dispatched back to 
the IO thread, then the proxy process takes place entirely using 
non-blocking IO in the IO thread.

Stuart

Bill Burke wrote:
> I removed the isInIoThread() check in a fork of
> AuthenticationCallHandler.  Hopefully this is correct.
>
> On 12/5/2014 4:48 PM, Bill Burke wrote:
>> I'm using the Undertow ProxyHandler, should I be executing the
>> ProxyHandler in a separate thread?  What I"m running into right now is
>> that I'm making a nested HTTP call within a Servlet request ( GET
>> http://proxy.com which invokes a call to http://proxy.com/test) and the
>> 2nd call isn't getting through.
>>
>> The nested call never gets passed AuthenticationCallHandler line 46.
>>
>>
>

From sdouglas at redhat.com  Fri Dec  5 21:10:22 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sat, 06 Dec 2014 13:10:22 +1100
Subject: [undertow-dev] HTTP/2 REST API
In-Reply-To: <CA+TL3n3N+FirLFqtY6coiuQsWw7tL0oTEg21tDpXM2uJAR9SKA@mail.gmail.com>
References: <CA+TL3n3N+FirLFqtY6coiuQsWw7tL0oTEg21tDpXM2uJAR9SKA@mail.gmail.com>
Message-ID: <5482658E.8090509@redhat.com>

There is an example of exactly what you are after here:

https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/http2/Http2Server.java

It has a HTTP2/SPDY server listening on https://localhost:8443.

It also defines a reverse proxy that connects to this that is listening 
on https://localhost:8444.

The reverse proxy is SPDY/HTTP2 aware, so server push will still work 
through the reverse proxy (as of yesterday).

Stuart

Davide Ungari wrote:
> Hi,
> I would like to understand how to make a REST API with RestEasy and
> Undertow be served with HTTP/2 or SPDY. How have I to configure Undertow?
>
> I have a frontend application running on Undertow calling this REST API
> on another Undertow instance. How can I configure both to use HTTP/2?
>
> Does all this "optimization" make sense?
>
> Thanks everybody
>
> --
> Davide
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bburke at redhat.com  Fri Dec  5 21:12:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 21:12:00 -0500
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <548264D1.4040904@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
	<548264D1.4040904@redhat.com>
Message-ID: <548265F0.6080403@redhat.com>

Servlet is involved only indirectly:

client->proxy->tomcat->proxy->tomcat

that's the call structure.  Code is here:

https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyServerBuilder.java

On 12/5/2014 9:07 PM, Stuart Douglas wrote:
> The reason why that check is there is that the authenticate call may
> involve blocking operations, which you should not do in an IO thread.
>
> Can I have a look at the code? The proxy handler will only execute in
> the IO thread, and is not really servlet aware, so I have not really
> though about how they will work together (you may need to call
> startAsync() on the servlet request).
>
> The reason for this design is that the proxy handler connects to the
> target server using the same IO thread as the original request. This
> means that there is only ever one thread involved in the proxy process,
> and we don't need to use any kind of synchronization.
>
> If the request is running in a worker thread it is dispatched back to
> the IO thread, then the proxy process takes place entirely using
> non-blocking IO in the IO thread.
>
> Stuart
>
> Bill Burke wrote:
>> I removed the isInIoThread() check in a fork of
>> AuthenticationCallHandler.  Hopefully this is correct.
>>
>> On 12/5/2014 4:48 PM, Bill Burke wrote:
>>> I'm using the Undertow ProxyHandler, should I be executing the
>>> ProxyHandler in a separate thread?  What I"m running into right now is
>>> that I'm making a nested HTTP call within a Servlet request ( GET
>>> http://proxy.com which invokes a call to http://proxy.com/test) and the
>>> 2nd call isn't getting through.
>>>
>>> The nested call never gets passed AuthenticationCallHandler line 46.
>>>
>>>
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Fri Dec  5 21:26:31 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sat, 06 Dec 2014 13:26:31 +1100
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <548265F0.6080403@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
	<548264D1.4040904@redhat.com> <548265F0.6080403@redhat.com>
Message-ID: <54826957.4020801@redhat.com>

So if everything is working correctly the only way that dispatch call 
would break is if the worker thread pool is exhausted somehow, which 
seems unlikely, as by default this should be fairly large.

Stuart

Bill Burke wrote:
> Servlet is involved only indirectly:
>
> client->proxy->tomcat->proxy->tomcat
>
> that's the call structure. Code is here:
>
> https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyServerBuilder.java
>
>
> On 12/5/2014 9:07 PM, Stuart Douglas wrote:
>> The reason why that check is there is that the authenticate call may
>> involve blocking operations, which you should not do in an IO thread.
>>
>> Can I have a look at the code? The proxy handler will only execute in
>> the IO thread, and is not really servlet aware, so I have not really
>> though about how they will work together (you may need to call
>> startAsync() on the servlet request).
>>
>> The reason for this design is that the proxy handler connects to the
>> target server using the same IO thread as the original request. This
>> means that there is only ever one thread involved in the proxy process,
>> and we don't need to use any kind of synchronization.
>>
>> If the request is running in a worker thread it is dispatched back to
>> the IO thread, then the proxy process takes place entirely using
>> non-blocking IO in the IO thread.
>>
>> Stuart
>>
>> Bill Burke wrote:
>>> I removed the isInIoThread() check in a fork of
>>> AuthenticationCallHandler. Hopefully this is correct.
>>>
>>> On 12/5/2014 4:48 PM, Bill Burke wrote:
>>>> I'm using the Undertow ProxyHandler, should I be executing the
>>>> ProxyHandler in a separate thread? What I"m running into right now is
>>>> that I'm making a nested HTTP call within a Servlet request ( GET
>>>> http://proxy.com which invokes a call to http://proxy.com/test) and the
>>>> 2nd call isn't getting through.
>>>>
>>>> The nested call never gets passed AuthenticationCallHandler line 46.
>>>>
>>>>
>>>
>

From bburke at redhat.com  Sat Dec  6 09:04:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 06 Dec 2014 09:04:00 -0500
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <54826957.4020801@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
	<548264D1.4040904@redhat.com> <548265F0.6080403@redhat.com>
	<54826957.4020801@redhat.com>
Message-ID: <54830CD0.9010306@redhat.com>

So removing the isInIoThread() check is ok?

On 12/5/2014 9:26 PM, Stuart Douglas wrote:
> So if everything is working correctly the only way that dispatch call
> would break is if the worker thread pool is exhausted somehow, which
> seems unlikely, as by default this should be fairly large.
>
> Stuart
>
> Bill Burke wrote:
>> Servlet is involved only indirectly:
>>
>> client->proxy->tomcat->proxy->tomcat
>>
>> that's the call structure. Code is here:
>>
>> https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyServerBuilder.java
>>
>>
>>
>> On 12/5/2014 9:07 PM, Stuart Douglas wrote:
>>> The reason why that check is there is that the authenticate call may
>>> involve blocking operations, which you should not do in an IO thread.
>>>
>>> Can I have a look at the code? The proxy handler will only execute in
>>> the IO thread, and is not really servlet aware, so I have not really
>>> though about how they will work together (you may need to call
>>> startAsync() on the servlet request).
>>>
>>> The reason for this design is that the proxy handler connects to the
>>> target server using the same IO thread as the original request. This
>>> means that there is only ever one thread involved in the proxy process,
>>> and we don't need to use any kind of synchronization.
>>>
>>> If the request is running in a worker thread it is dispatched back to
>>> the IO thread, then the proxy process takes place entirely using
>>> non-blocking IO in the IO thread.
>>>
>>> Stuart
>>>
>>> Bill Burke wrote:
>>>> I removed the isInIoThread() check in a fork of
>>>> AuthenticationCallHandler. Hopefully this is correct.
>>>>
>>>> On 12/5/2014 4:48 PM, Bill Burke wrote:
>>>>> I'm using the Undertow ProxyHandler, should I be executing the
>>>>> ProxyHandler in a separate thread? What I"m running into right now is
>>>>> that I'm making a nested HTTP call within a Servlet request ( GET
>>>>> http://proxy.com which invokes a call to http://proxy.com/test) and
>>>>> the
>>>>> 2nd call isn't getting through.
>>>>>
>>>>> The nested call never gets passed AuthenticationCallHandler line 46.
>>>>>
>>>>>
>>>>
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Sun Dec  7 04:12:54 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 07 Dec 2014 20:12:54 +1100
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <54830CD0.9010306@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
	<548264D1.4040904@redhat.com> <548265F0.6080403@redhat.com>
	<54826957.4020801@redhat.com> <54830CD0.9010306@redhat.com>
Message-ID: <54841A16.8070602@redhat.com>

In your case I think it is, as your IdentityManager won't block (it is always safe, its just that perf might suck in some cases). 

I would still like to get to the bottom of this though, how do I reproduce this?

Stuart

Bill Burke wrote:
> So removing the isInIoThread() check is ok?
>
> On 12/5/2014 9:26 PM, Stuart Douglas wrote:
>> So if everything is working correctly the only way that dispatch call
>> would break is if the worker thread pool is exhausted somehow, which
>> seems unlikely, as by default this should be fairly large.
>>
>> Stuart
>>
>> Bill Burke wrote:
>>> Servlet is involved only indirectly:
>>>
>>> client->proxy->tomcat->proxy->tomcat
>>>
>>> that's the call structure. Code is here:
>>>
>>> https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyServerBuilder.java 
>>>
>>>
>>>
>>>
>>> On 12/5/2014 9:07 PM, Stuart Douglas wrote:
>>>> The reason why that check is there is that the authenticate call may
>>>> involve blocking operations, which you should not do in an IO thread.
>>>>
>>>> Can I have a look at the code? The proxy handler will only execute in
>>>> the IO thread, and is not really servlet aware, so I have not really
>>>> though about how they will work together (you may need to call
>>>> startAsync() on the servlet request).
>>>>
>>>> The reason for this design is that the proxy handler connects to the
>>>> target server using the same IO thread as the original request. This
>>>> means that there is only ever one thread involved in the proxy 
>>>> process,
>>>> and we don't need to use any kind of synchronization.
>>>>
>>>> If the request is running in a worker thread it is dispatched back to
>>>> the IO thread, then the proxy process takes place entirely using
>>>> non-blocking IO in the IO thread.
>>>>
>>>> Stuart
>>>>
>>>> Bill Burke wrote:
>>>>> I removed the isInIoThread() check in a fork of
>>>>> AuthenticationCallHandler. Hopefully this is correct.
>>>>>
>>>>> On 12/5/2014 4:48 PM, Bill Burke wrote:
>>>>>> I'm using the Undertow ProxyHandler, should I be executing the
>>>>>> ProxyHandler in a separate thread? What I"m running into right 
>>>>>> now is
>>>>>> that I'm making a nested HTTP call within a Servlet request ( GET
>>>>>> http://proxy.com which invokes a call to http://proxy.com/test) and
>>>>>> the
>>>>>> 2nd call isn't getting through.
>>>>>>
>>>>>> The nested call never gets passed AuthenticationCallHandler line 46.
>>>>>>
>>>>>>
>>>>>
>>>
>

From bburke at redhat.com  Sun Dec  7 09:33:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 07 Dec 2014 09:33:45 -0500
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <54841A16.8070602@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
	<548264D1.4040904@redhat.com> <548265F0.6080403@redhat.com>
	<54826957.4020801@redhat.com> <54830CD0.9010306@redhat.com>
	<54841A16.8070602@redhat.com>
Message-ID: <54846549.7020501@redhat.com>

In ProxyServerBuilder line 228 change ProxyAuthenticationCallHandler to 
Undertow's AuthenticationCallHandler.

Test:

https://github.com/patriot1burke/keycloak/blob/master/testsuite/proxy/src/test/java/org/keycloak/testsuite/ProxyTest.java

Run testHttp()

You'll see that ProxyTest line 127 returns 200 with empty data.  If you 
run in debugger you can see isInIoThread() check executing in the 
AUthenticationCallHandler.

On 12/7/2014 4:12 AM, Stuart Douglas wrote:
> In your case I think it is, as your IdentityManager won't block (it is
> always safe, its just that perf might suck in some cases).
> I would still like to get to the bottom of this though, how do I
> reproduce this?
>
> Stuart
>
> Bill Burke wrote:
>> So removing the isInIoThread() check is ok?
>>
>> On 12/5/2014 9:26 PM, Stuart Douglas wrote:
>>> So if everything is working correctly the only way that dispatch call
>>> would break is if the worker thread pool is exhausted somehow, which
>>> seems unlikely, as by default this should be fairly large.
>>>
>>> Stuart
>>>
>>> Bill Burke wrote:
>>>> Servlet is involved only indirectly:
>>>>
>>>> client->proxy->tomcat->proxy->tomcat
>>>>
>>>> that's the call structure. Code is here:
>>>>
>>>> https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyServerBuilder.java
>>>>
>>>>
>>>>
>>>>
>>>> On 12/5/2014 9:07 PM, Stuart Douglas wrote:
>>>>> The reason why that check is there is that the authenticate call may
>>>>> involve blocking operations, which you should not do in an IO thread.
>>>>>
>>>>> Can I have a look at the code? The proxy handler will only execute in
>>>>> the IO thread, and is not really servlet aware, so I have not really
>>>>> though about how they will work together (you may need to call
>>>>> startAsync() on the servlet request).
>>>>>
>>>>> The reason for this design is that the proxy handler connects to the
>>>>> target server using the same IO thread as the original request. This
>>>>> means that there is only ever one thread involved in the proxy
>>>>> process,
>>>>> and we don't need to use any kind of synchronization.
>>>>>
>>>>> If the request is running in a worker thread it is dispatched back to
>>>>> the IO thread, then the proxy process takes place entirely using
>>>>> non-blocking IO in the IO thread.
>>>>>
>>>>> Stuart
>>>>>
>>>>> Bill Burke wrote:
>>>>>> I removed the isInIoThread() check in a fork of
>>>>>> AuthenticationCallHandler. Hopefully this is correct.
>>>>>>
>>>>>> On 12/5/2014 4:48 PM, Bill Burke wrote:
>>>>>>> I'm using the Undertow ProxyHandler, should I be executing the
>>>>>>> ProxyHandler in a separate thread? What I"m running into right
>>>>>>> now is
>>>>>>> that I'm making a nested HTTP call within a Servlet request ( GET
>>>>>>> http://proxy.com which invokes a call to http://proxy.com/test) and
>>>>>>> the
>>>>>>> 2nd call isn't getting through.
>>>>>>>
>>>>>>> The nested call never gets passed AuthenticationCallHandler line 46.
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Sun Dec  7 17:05:50 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 08 Dec 2014 09:05:50 +1100
Subject: [undertow-dev] exchange.isInIoThread()
In-Reply-To: <54846549.7020501@redhat.com>
References: <54822824.3000205@redhat.com> <54823AA7.5060208@redhat.com>
	<548264D1.4040904@redhat.com> <548265F0.6080403@redhat.com>
	<54826957.4020801@redhat.com> <54830CD0.9010306@redhat.com>
	<54841A16.8070602@redhat.com> <54846549.7020501@redhat.com>
Message-ID: <5484CF3E.7060209@redhat.com>

I don't see this, the test is passing for me and the correct data is 
being returned.

I am trying to think of what could cause the situation you describe. One 
would be that if an earlier handler ends the exchange but then calls the 
next handler anyway with an exchange that is already done.

Another would be that if there was another thread involved somehow.

Without being able to reproduce it locally it is hard to say for sure.

Stuart

Bill Burke wrote:
> In ProxyServerBuilder line 228 change ProxyAuthenticationCallHandler to
> Undertow's AuthenticationCallHandler.
>
> Test:
>
> https://github.com/patriot1burke/keycloak/blob/master/testsuite/proxy/src/test/java/org/keycloak/testsuite/ProxyTest.java
>
>
> Run testHttp()
>
> You'll see that ProxyTest line 127 returns 200 with empty data. If you
> run in debugger you can see isInIoThread() check executing in the
> AUthenticationCallHandler.
>
> On 12/7/2014 4:12 AM, Stuart Douglas wrote:
>> In your case I think it is, as your IdentityManager won't block (it is
>> always safe, its just that perf might suck in some cases).
>> I would still like to get to the bottom of this though, how do I
>> reproduce this?
>>
>> Stuart
>>
>> Bill Burke wrote:
>>> So removing the isInIoThread() check is ok?
>>>
>>> On 12/5/2014 9:26 PM, Stuart Douglas wrote:
>>>> So if everything is working correctly the only way that dispatch call
>>>> would break is if the worker thread pool is exhausted somehow, which
>>>> seems unlikely, as by default this should be fairly large.
>>>>
>>>> Stuart
>>>>
>>>> Bill Burke wrote:
>>>>> Servlet is involved only indirectly:
>>>>>
>>>>> client->proxy->tomcat->proxy->tomcat
>>>>>
>>>>> that's the call structure. Code is here:
>>>>>
>>>>> https://github.com/keycloak/keycloak/blob/master/proxy/proxy-server/src/main/java/org/keycloak/proxy/ProxyServerBuilder.java
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/5/2014 9:07 PM, Stuart Douglas wrote:
>>>>>> The reason why that check is there is that the authenticate call may
>>>>>> involve blocking operations, which you should not do in an IO thread.
>>>>>>
>>>>>> Can I have a look at the code? The proxy handler will only execute in
>>>>>> the IO thread, and is not really servlet aware, so I have not really
>>>>>> though about how they will work together (you may need to call
>>>>>> startAsync() on the servlet request).
>>>>>>
>>>>>> The reason for this design is that the proxy handler connects to the
>>>>>> target server using the same IO thread as the original request. This
>>>>>> means that there is only ever one thread involved in the proxy
>>>>>> process,
>>>>>> and we don't need to use any kind of synchronization.
>>>>>>
>>>>>> If the request is running in a worker thread it is dispatched back to
>>>>>> the IO thread, then the proxy process takes place entirely using
>>>>>> non-blocking IO in the IO thread.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> Bill Burke wrote:
>>>>>>> I removed the isInIoThread() check in a fork of
>>>>>>> AuthenticationCallHandler. Hopefully this is correct.
>>>>>>>
>>>>>>> On 12/5/2014 4:48 PM, Bill Burke wrote:
>>>>>>>> I'm using the Undertow ProxyHandler, should I be executing the
>>>>>>>> ProxyHandler in a separate thread? What I"m running into right
>>>>>>>> now is
>>>>>>>> that I'm making a nested HTTP call within a Servlet request ( GET
>>>>>>>> http://proxy.com which invokes a call to http://proxy.com/test) and
>>>>>>>> the
>>>>>>>> 2nd call isn't getting through.
>>>>>>>>
>>>>>>>> The nested call never gets passed AuthenticationCallHandler line
>>>>>>>> 46.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>

From laurent at labe.me  Fri Dec 12 13:11:01 2014
From: laurent at labe.me (Laurent Bedubourg)
Date: Fri, 12 Dec 2014 18:11:01 +0000
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
Message-ID: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>

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)
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141212/351480c3/attachment-0001.html 

From laurent at labe.me  Fri Dec 12 16:44:27 2014
From: laurent at labe.me (Laurent Bedubourg)
Date: Fri, 12 Dec 2014 21:44:27 +0000
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
References: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>
Message-ID: <CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>

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 at 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)
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141212/5d8cc314/attachment.html 

From jason.greene at redhat.com  Fri Dec 12 22:51:53 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 12 Dec 2014 21:51:53 -0600
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
In-Reply-To: <CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>
References: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>
	<CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>
Message-ID: <BAC61CA5-EB84-4D2F-826A-642608702428@redhat.com>

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 at 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 at 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 at 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



From laurent at labe.me  Sat Dec 13 02:58:51 2014
From: laurent at labe.me (Laurent Bedubourg)
Date: Sat, 13 Dec 2014 07:58:51 +0000
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
References: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>
	<CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>
	<BAC61CA5-EB84-4D2F-826A-642608702428@redhat.com>
Message-ID: <CAK84i07cWKUqueWTrqzu3-=BO=4y+B+sN9sVReKLjJgSJMC64w@mail.gmail.com>

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 at 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 at 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141213/885f8ef7/attachment-0001.html 

From lbedubourg at gmail.com  Sat Dec 13 04:54:40 2014
From: lbedubourg at gmail.com (Laurent Bedubourg)
Date: Sat, 13 Dec 2014 09:54:40 +0000
Subject: [undertow-dev] UTF8 form parsing
Message-ID: <CAK84i07Ea_9pb-sGvXveF0QRmhmH7FGB5N2cA58oSR1bJhk46Q@mail.gmail.com>

Hello,

I am using utf-8 as default encoding for the web and it didn't worked out
of the box with Undertow and EagerFormParsingHandler.

It turned out that MultiPartParserDefinition has a default iso-8859-1
encoding and that it's quite hard to change it. You have to create a custom
FormParserFactory containing a MultiPartParserDefinition with the right
setDefaultEncoding() that's a lot of work for something that common and I
had to spend half an hour looking at Undertow sources to understand how it
work and why my input was garbage.

The assumption that Browsers will add a "; charset=UTF-8" to the Content
type is false (at least with google chrome).

My temporary hack is to override EagerFormParsingHandler and modify the
request CONTENT_TYPE header to add the UTF-8 charset and then setNext my
real HttpHandler (I had less mental friction doing this than learning how
to create my custom FormParserFactor).

new EagerFormParsingHandler(){
  override def handleRequest(x:HttpServerExchange){
    val ct = x.getRequestHeaders().get(Headers.CONTENT_TYPE).getLast()
    x.getRequestHeaders().put(Headers.CONTENT_TYPE, ct+"; charset=UTF-8")
    super.handleRequest(x)
  }
}.setNext(new HttpHandler(){
  def handleRequest(x:HttpServerExchange){ ... }
})

Now that I know it I can create my own Utf8FormParsingHandler but I imagine
that other users will want to be able to define the encoding out of the box.

Maybe with a new self documenting contructor like :

new EagerFormParsingHandler(encoding:String, nextHandler:HttpHandler)

Best regards
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141213/1190ad43/attachment.html 

From sdouglas at redhat.com  Sun Dec 14 17:27:48 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 14 Dec 2014 17:27:48 -0500 (EST)
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
In-Reply-To: <CAK84i07cWKUqueWTrqzu3-=BO=4y+B+sN9sVReKLjJgSJMC64w@mail.gmail.com>
References: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>
	<CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>
	<BAC61CA5-EB84-4D2F-826A-642608702428@redhat.com>
	<CAK84i07cWKUqueWTrqzu3-=BO=4y+B+sN9sVReKLjJgSJMC64w@mail.gmail.com>
Message-ID: <1757318743.12717938.1418596068704.JavaMail.zimbra@redhat.com>

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 at labe.me>
> To: "Jason Greene" <jason.greene at redhat.com>
> Cc: undertow-dev at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
> 
> > https://lists.jboss.org/ mailman/listinfo/undertow-dev
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141214/722996b8/attachment.html 

From sdouglas at redhat.com  Sun Dec 14 18:06:42 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 14 Dec 2014 18:06:42 -0500 (EST)
Subject: [undertow-dev] UTF8 form parsing
In-Reply-To: <CAK84i07Ea_9pb-sGvXveF0QRmhmH7FGB5N2cA58oSR1bJhk46Q@mail.gmail.com>
References: <CAK84i07Ea_9pb-sGvXveF0QRmhmH7FGB5N2cA58oSR1bJhk46Q@mail.gmail.com>
Message-ID: <1551816304.12720797.1418598402186.JavaMail.zimbra@redhat.com>

I have created https://issues.jboss.org/browse/UNDERTOW-356, I will probably get to it some time this week.

BTW the reason why it defaults to ISO-8859-1 is because this is what the HTTP RFC says is the default, however it appears that in practice often browsers don't know the charset.

Stuart

----- Original Message -----
> From: "Laurent Bedubourg" <lbedubourg at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 13 December, 2014 8:54:40 PM
> Subject: [undertow-dev] UTF8 form parsing
> 
> Hello,
> 
> I am using utf-8 as default encoding for the web and it didn't worked out of
> the box with Undertow and EagerFormParsingHandler.
> 
> It turned out that MultiPartParserDefinition has a default iso-8859-1
> encoding and that it's quite hard to change it. You have to create a custom
> FormParserFactory containing a MultiPartParserDefinition with the right
> setDefaultEncoding() that's a lot of work for something that common and I
> had to spend half an hour looking at Undertow sources to understand how it
> work and why my input was garbage.
> 
> The assumption that Browsers will add a "; charset=UTF-8" to the Content type
> is false (at least with google chrome).
> 
> My temporary hack is to override EagerFormParsingHandler and modify the
> request CONTENT_TYPE header to add the UTF-8 charset and then setNext my
> real HttpHandler (I had less mental friction doing this than learning how to
> create my custom FormParserFactor).
> 
> new EagerFormParsingHandler(){
> override def handleRequest(x:HttpServerExchange){
> val ct = x.getRequestHeaders().get(Headers.CONTENT_TYPE).getLast()
> x.getRequestHeaders().put(Headers.CONTENT_TYPE, ct+"; charset=UTF-8")
> super.handleRequest(x)
> }
> }.setNext(new HttpHandler(){
> def handleRequest(x:HttpServerExchange){ ... }
> })
> 
> Now that I know it I can create my own Utf8FormParsingHandler but I imagine
> that other users will want to be able to define the encoding out of the box.
> 
> Maybe with a new self documenting contructor like :
> 
> new EagerFormParsingHandler(encoding:String, nextHandler:HttpHandler)
> 
> Best regards
> Laurent
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From laurent at labe.me  Mon Dec 15 01:56:51 2014
From: laurent at labe.me (Laurent Bedubourg)
Date: Mon, 15 Dec 2014 06:56:51 +0000
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
References: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>
	<CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>
	<BAC61CA5-EB84-4D2F-826A-642608702428@redhat.com>
	<CAK84i07cWKUqueWTrqzu3-=BO=4y+B+sN9sVReKLjJgSJMC64w@mail.gmail.com>
	<1757318743.12717938.1418596068704.JavaMail.zimbra@redhat.com>
Message-ID: <CAK84i06t776sKVD3b0W8h1Run_MQJoZvv24kZ5AB10X-MA-fUA@mail.gmail.com>

Thank you Stuart, I will try this ASAP.

Best regards
Laurent

On Sun, 14 Dec 2014 23:28 Stuart Douglas <sdouglas at 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 at labe.me>
> *To: *"Jason Greene" <jason.greene at redhat.com>
> *Cc: *undertow-dev at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141215/e6250e78/attachment.html 

From lbedubourg at gmail.com  Mon Dec 15 01:57:43 2014
From: lbedubourg at gmail.com (Laurent Bedubourg)
Date: Mon, 15 Dec 2014 06:57:43 +0000
Subject: [undertow-dev] UTF8 form parsing
References: <CAK84i07Ea_9pb-sGvXveF0QRmhmH7FGB5N2cA58oSR1bJhk46Q@mail.gmail.com>
	<1551816304.12720797.1418598402186.JavaMail.zimbra@redhat.com>
Message-ID: <CAK84i041G6MskxnfkH-0Du3pyYjtfE+is0g-acQ2cDy0DN1xdA@mail.gmail.com>

Thanks again !

On Mon, 15 Dec 2014 00:06 Stuart Douglas <sdouglas at redhat.com> wrote:

> I have created https://issues.jboss.org/browse/UNDERTOW-356, I will
> probably get to it some time this week.
>
> BTW the reason why it defaults to ISO-8859-1 is because this is what the
> HTTP RFC says is the default, however it appears that in practice often
> browsers don't know the charset.
>
> Stuart
>
> ----- Original Message -----
> > From: "Laurent Bedubourg" <lbedubourg at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Saturday, 13 December, 2014 8:54:40 PM
> > Subject: [undertow-dev] UTF8 form parsing
> >
> > Hello,
> >
> > I am using utf-8 as default encoding for the web and it didn't worked
> out of
> > the box with Undertow and EagerFormParsingHandler.
> >
> > It turned out that MultiPartParserDefinition has a default iso-8859-1
> > encoding and that it's quite hard to change it. You have to create a
> custom
> > FormParserFactory containing a MultiPartParserDefinition with the right
> > setDefaultEncoding() that's a lot of work for something that common and I
> > had to spend half an hour looking at Undertow sources to understand how
> it
> > work and why my input was garbage.
> >
> > The assumption that Browsers will add a "; charset=UTF-8" to the Content
> type
> > is false (at least with google chrome).
> >
> > My temporary hack is to override EagerFormParsingHandler and modify the
> > request CONTENT_TYPE header to add the UTF-8 charset and then setNext my
> > real HttpHandler (I had less mental friction doing this than learning
> how to
> > create my custom FormParserFactor).
> >
> > new EagerFormParsingHandler(){
> > override def handleRequest(x:HttpServerExchange){
> > val ct = x.getRequestHeaders().get(Headers.CONTENT_TYPE).getLast()
> > x.getRequestHeaders().put(Headers.CONTENT_TYPE, ct+"; charset=UTF-8")
> > super.handleRequest(x)
> > }
> > }.setNext(new HttpHandler(){
> > def handleRequest(x:HttpServerExchange){ ... }
> > })
> >
> > Now that I know it I can create my own Utf8FormParsingHandler but I
> imagine
> > that other users will want to be able to define the encoding out of the
> box.
> >
> > Maybe with a new self documenting contructor like :
> >
> > new EagerFormParsingHandler(encoding:String, nextHandler:HttpHandler)
> >
> > Best regards
> > Laurent
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141215/887d7baf/attachment-0001.html 

From laurent at labe.me  Mon Dec 15 06:40:19 2014
From: laurent at labe.me (Laurent Bedubourg)
Date: Mon, 15 Dec 2014 11:40:19 +0000
Subject: [undertow-dev] scala, activate, nio, async jdbc, future, threads
References: <CAK84i07iM4XN2-=aZeGdhuc=EhQKh+_gyVFqKeUPzhKQ9ru5SQ@mail.gmail.com>
	<CAK84i06U-q5OEa6Dkzyb3tKO16AYGw72fBw1KJdcrPXuv2-7yg@mail.gmail.com>
	<BAC61CA5-EB84-4D2F-826A-642608702428@redhat.com>
	<CAK84i07cWKUqueWTrqzu3-=BO=4y+B+sN9sVReKLjJgSJMC64w@mail.gmail.com>
	<1757318743.12717938.1418596068704.JavaMail.zimbra@redhat.com>
	<CAK84i06t776sKVD3b0W8h1Run_MQJoZvv24kZ5AB10X-MA-fUA@mail.gmail.com>
Message-ID: <CAK84i0656fDu+FCUzTo=1sp5gPZd0-Vx0hqkVtX3M98w3=f4vA@mail.gmail.com>

Works like a charm, thanks again.

On Mon Dec 15 2014 at 7:56:49 AM Laurent Bedubourg <laurent at labe.me> wrote:

> Thank you Stuart, I will try this ASAP.
>
> Best regards
> Laurent
>
> On Sun, 14 Dec 2014 23:28 Stuart Douglas <sdouglas at 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 at labe.me>
>> *To: *"Jason Greene" <jason.greene at redhat.com>
>> *Cc: *undertow-dev at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141215/b30cad1a/attachment.html 

From dsimansk at redhat.com  Mon Dec 15 09:32:44 2014
From: dsimansk at redhat.com (David Simansky)
Date: Mon, 15 Dec 2014 09:32:44 -0500 (EST)
Subject: [undertow-dev] Undertow http client
In-Reply-To: <1579212745.13458856.1418653661697.JavaMail.zimbra@redhat.com>
Message-ID: <1271150437.13465376.1418653964883.JavaMail.zimbra@redhat.com>

Hi all,

I have a question regarding Undertow http client. I would like to achieve something similar to what jetty http client or apache http clients can do. Pretty much just send out http requests with different kind of method(+possibly include payload). The question is, if the undertow client classes are meant to be used that way because my google search haven't found any example of usage like that. Is there any convenient way I could go for?

Thanks,
David



From sdouglas at redhat.com  Mon Dec 15 13:52:03 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 15 Dec 2014 13:52:03 -0500 (EST)
Subject: [undertow-dev] Undertow http client
In-Reply-To: <1271150437.13465376.1418653964883.JavaMail.zimbra@redhat.com>
References: <1271150437.13465376.1418653964883.JavaMail.zimbra@redhat.com>
Message-ID: <1136876946.13323694.1418669523377.JavaMail.zimbra@redhat.com>

The Undertow HTTP client was designed to be used in the reverse proxy, not so much as a general purpose HTTP client. 

The only real example of how to use it is at io.undertow.server.handlers.proxy.ProxyHandler, where it is used in the reverse proxy. 

It supports HTTP, AJP, SPDY and the current draft of HTTP2.

It is 100% non-blocking and not thread safe, for the most part interaction with the client should be done in the IO thread of the connection. There has been some talk about adding a blocking/thread safe wrapper at some stage. 

The basic way that it is used is:
- Connect to the remote host
- Create a ClientRequest object and populate it with headers etc
- Call ClientConnection.sendRequest with your request and a callback. When the connection is ready to send your request the callback will be invoked
- If you want a request body use ClientExchange.getRequestChannel() to get a channel to use for sending
- ClientExchange.setResponseListener() is used to register a listener to be notified of a response (you can also set handlers for HTTP 101 continue and server push events)
- Once the response listener has been invoked you can get the client response from the exchange

Stuart

----- Original Message -----
> From: "David Simansky" <dsimansk at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 1:32:44 AM
> Subject: [undertow-dev] Undertow http client
> 
> Hi all,
> 
> I have a question regarding Undertow http client. I would like to achieve
> something similar to what jetty http client or apache http clients can do.
> Pretty much just send out http requests with different kind of
> method(+possibly include payload). The question is, if the undertow client
> classes are meant to be used that way because my google search haven't found
> any example of usage like that. Is there any convenient way I could go for?
> 
> Thanks,
> David
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From bburke at redhat.com  Mon Dec 22 10:34:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 10:34:47 -0500
Subject: [undertow-dev] AuthMechanism called always?
Message-ID: <54983A17.4090004@redhat.com>

A user is reporting that our Keycloak AuthMechanism is being called even 
with unsecured resources.  They have constraints defined in web.xml, but 
if the constraint is unmatched (unsecure) the mechanism is still called.

Why is the auth mechanism called for unsecure resources?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Dec 22 16:03:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 16:03:42 -0500
Subject: [undertow-dev] AuthMechanism called always?
In-Reply-To: <54983A17.4090004@redhat.com>
References: <54983A17.4090004@redhat.com>
Message-ID: <5498872E.309@redhat.com>

Nevermind...You need this to queue up challenges just in case 
ServletRequest.authenticate() is invoked.

On 12/22/2014 10:34 AM, Bill Burke wrote:
> A user is reporting that our Keycloak AuthMechanism is being called even
> with unsecured resources.  They have constraints defined in web.xml, but
> if the constraint is unmatched (unsecure) the mechanism is still called.
>
> Why is the auth mechanism called for unsecure resources?
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From arjan.tijms at gmail.com  Mon Dec 22 16:12:45 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 22 Dec 2014 22:12:45 +0100
Subject: [undertow-dev] AuthMechanism called always?
In-Reply-To: <5498872E.309@redhat.com>
References: <54983A17.4090004@redhat.com>
	<5498872E.309@redhat.com>
Message-ID: <CAE=-AhBRU8E2Tskg8Bh=ToP4Oq-Sv6gzhxkbsDKwJ+-+0ryV_Q@mail.gmail.com>

Hi,

On Mon, Dec 22, 2014 at 10:03 PM, Bill Burke <bburke at redhat.com> wrote:
> Nevermind...You need this to queue up challenges just in case
> ServletRequest.authenticate() is invoked.

I don't know Keycloak, but in general it's not so strange that an auth
mechanism is called for unsecured resources. More than a few security
systems do this.

The reason is not just to support ServletRequest.authenticate(), but
also to allow pre-emptive authentication for any resource. Being
authenticated is not something that's only needed for secured
resources; public resources can for instance show extra options when
authenticated.

Kind regards,
Arjan Tijms



>
> On 12/22/2014 10:34 AM, Bill Burke wrote:
>> A user is reporting that our Keycloak AuthMechanism is being called even
>> with unsecured resources.  They have constraints defined in web.xml, but
>> if the constraint is unmatched (unsecure) the mechanism is still called.
>>
>> Why is the auth mechanism called for unsecure resources?
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bburke at redhat.com  Mon Dec 22 16:28:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 16:28:26 -0500
Subject: [undertow-dev] req.authenticate() problems 1.1.0
In-Reply-To: <416836001.6544247.1417479519254.JavaMail.zimbra@redhat.com>
References: <5474AEB1.8030405@redhat.com>
	<1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com>
	<88575048.4255911.1416948115410.JavaMail.zimbra@redhat.com>
	<547C85AC.3050606@redhat.com>
	<416836001.6544247.1417479519254.JavaMail.zimbra@redhat.com>
Message-ID: <54988CFA.2080202@redhat.com>

Looks like Undertow 1.1.1.Final didn't make Wildfly 8.2 cut.  Will there 
even be a Wildfly 8.2.1?

On 12/1/2014 7:18 PM, Stuart Douglas wrote:
> I have cut 1.1.1.Final
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 2:13:48 AM
>> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
>>
>> 1.1.1 or 1.2.x release incoming?  We're doing a keycloak release with
>> the proxy this week, just wondering if I should delay if undertow is
>> incoming so I can upgrade the proxy distro.
>>
>> On 11/25/2014 3:41 PM, Stuart Douglas wrote:
>>> This should be fixed upstream, I will do a 1.1.1 release shortly, so if you
>>> discover any other issues let me know and I will try and get them into
>>> this release.
>>>
>>> Stuart
>>>
>>> ----- Original Message -----
>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>>> To: "Bill Burke" <bburke at redhat.com>
>>>> Cc: undertow-dev at lists.jboss.org
>>>> Sent: Wednesday, 26 November, 2014 6:19:41 AM
>>>> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
>>>>
>>>> Is the code up on Github anywhere? If so I can take a look.
>>>>
>>>> Stuart
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: undertow-dev at lists.jboss.org
>>>>> Sent: Wednesday, 26 November, 2014 3:30:41 AM
>>>>> Subject: [undertow-dev] req.authenticate() problems 1.1.0
>>>>>
>>>>> When upgrading from Undertow 1.0.15 to 1.1.0 our
>>>>> HttpServleRequest.authenticate() unit test is failing.  An exception is
>>>>> being thrown in HttpServletRequestImpl.authenticate() line 416.
>>>>>
>>>>> Our auth mechanism is being called correctly.  It sets the status code
>>>>> (302) and the Location header within a challenge object.  It looks like
>>>>> exchange.isResponseStarted() is returning false even though my challenge
>>>>> object is setting up the resposne correctly.  Am I supposed to call
>>>>> exchange.endExchange() or something within my Challenge object?  I tried
>>>>> doing that, but Undertow is now spitting out exception messages:
>>>>>
>>>>> java.lang.IllegalStateException: UT000002: The response has already been
>>>>> started
>>>>> 	at
>>>>> io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109)
>>>>> 	at
>>>>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
>>>>> 	at
>>>>> io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404)
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Mon Dec 22 16:56:29 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 22 Dec 2014 16:56:29 -0500 (EST)
Subject: [undertow-dev] AuthMechanism called always?
In-Reply-To: <5498872E.309@redhat.com>
References: <54983A17.4090004@redhat.com> <5498872E.309@redhat.com>
Message-ID: <914368502.584856.1419285389586.JavaMail.zimbra@redhat.com>

We always authenticate if the credentials are supplied, there is a way to change this in undertow core by changing the AuthenticationMode from PRO_ACTIVE to CONSTRAINT_DRIVEN, however I just realised we have not actually added this option to Servlet deployments. I have added this option to Undertow upstream so 1.2.0 will support it. 



Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Tuesday, 23 December, 2014 8:03:42 AM
> Subject: Re: [undertow-dev] AuthMechanism called always?
> 
> Nevermind...You need this to queue up challenges just in case
> ServletRequest.authenticate() is invoked.
> 
> On 12/22/2014 10:34 AM, Bill Burke wrote:
> > A user is reporting that our Keycloak AuthMechanism is being called even
> > with unsecured resources.  They have constraints defined in web.xml, but
> > if the constraint is unmatched (unsecure) the mechanism is still called.
> >
> > Why is the auth mechanism called for unsecure resources?
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From sdouglas at redhat.com  Tue Dec 23 18:19:46 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 23 Dec 2014 18:19:46 -0500 (EST)
Subject: [undertow-dev] req.authenticate() problems 1.1.0
In-Reply-To: <54988CFA.2080202@redhat.com>
References: <5474AEB1.8030405@redhat.com>
	<1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com>
	<88575048.4255911.1416948115410.JavaMail.zimbra@redhat.com>
	<547C85AC.3050606@redhat.com>
	<416836001.6544247.1417479519254.JavaMail.zimbra@redhat.com>
	<54988CFA.2080202@redhat.com>
Message-ID: <2036368267.917403.1419376786919.JavaMail.zimbra@redhat.com>

At this stage there are no plans for one.

Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Tuesday, 23 December, 2014 8:28:26 AM
> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
> 
> Looks like Undertow 1.1.1.Final didn't make Wildfly 8.2 cut.  Will there
> even be a Wildfly 8.2.1?
> 
> On 12/1/2014 7:18 PM, Stuart Douglas wrote:
> > I have cut 1.1.1.Final
> >
> > Stuart
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stuart Douglas" <sdouglas at redhat.com>
> >> Cc: undertow-dev at lists.jboss.org
> >> Sent: Tuesday, 2 December, 2014 2:13:48 AM
> >> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
> >>
> >> 1.1.1 or 1.2.x release incoming?  We're doing a keycloak release with
> >> the proxy this week, just wondering if I should delay if undertow is
> >> incoming so I can upgrade the proxy distro.
> >>
> >> On 11/25/2014 3:41 PM, Stuart Douglas wrote:
> >>> This should be fixed upstream, I will do a 1.1.1 release shortly, so if
> >>> you
> >>> discover any other issues let me know and I will try and get them into
> >>> this release.
> >>>
> >>> Stuart
> >>>
> >>> ----- Original Message -----
> >>>> From: "Stuart Douglas" <sdouglas at redhat.com>
> >>>> To: "Bill Burke" <bburke at redhat.com>
> >>>> Cc: undertow-dev at lists.jboss.org
> >>>> Sent: Wednesday, 26 November, 2014 6:19:41 AM
> >>>> Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0
> >>>>
> >>>> Is the code up on Github anywhere? If so I can take a look.
> >>>>
> >>>> Stuart
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: undertow-dev at lists.jboss.org
> >>>>> Sent: Wednesday, 26 November, 2014 3:30:41 AM
> >>>>> Subject: [undertow-dev] req.authenticate() problems 1.1.0
> >>>>>
> >>>>> When upgrading from Undertow 1.0.15 to 1.1.0 our
> >>>>> HttpServleRequest.authenticate() unit test is failing.  An exception is
> >>>>> being thrown in HttpServletRequestImpl.authenticate() line 416.
> >>>>>
> >>>>> Our auth mechanism is being called correctly.  It sets the status code
> >>>>> (302) and the Location header within a challenge object.  It looks like
> >>>>> exchange.isResponseStarted() is returning false even though my
> >>>>> challenge
> >>>>> object is setting up the resposne correctly.  Am I supposed to call
> >>>>> exchange.endExchange() or something within my Challenge object?  I
> >>>>> tried
> >>>>> doing that, but Undertow is now spitting out exception messages:
> >>>>>
> >>>>> java.lang.IllegalStateException: UT000002: The response has already
> >>>>> been
> >>>>> started
> >>>>> 	at
> >>>>> io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109)
> >>>>> 	at
> >>>>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
> >>>>> 	at
> >>>>> io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404)
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Bill Burke
> >>>>> JBoss, a division of Red Hat
> >>>>> http://bill.burkecentral.com
> >>>>> _______________________________________________
> >>>>> undertow-dev mailing list
> >>>>> undertow-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>
> >>>> _______________________________________________
> >>>> undertow-dev mailing list
> >>>> undertow-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From karthickjagan at yahoo.com  Wed Dec 24 19:18:31 2014
From: karthickjagan at yahoo.com (Karthick V.J.)
Date: Thu, 25 Dec 2014 00:18:31 +0000 (UTC)
Subject: [undertow-dev] SEVERE: UT000004: getResponseChannel() has already
	been called
Message-ID: <775551943.700459.1419466712403.JavaMail.yahoo@jws10078.mail.ne1.yahoo.com>

Hi Undertow Devs,?
I was getting the below error in my application. ?I created a sample application which throws the same error (Attached is the sample applicaiton) ? ?When I added the exchange.dispatch() statement at line 158, the problem resolves. ? Is it required to dispatch () every time the context is switched to a new thread. ?Am I doing it right??

Thank You -?Karthick
Error:?
------------SEVERE: UT000004: getResponseChannel() has already been called
java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:208)
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:294)
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:270)
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:300)
.....
.....
.....
.....
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1181)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
at com.google.common.util.concurrent.Futures$ChainingListenableFuture$1.run(Futures.java:872)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.Futures$ImmediateFuture.addListener(Futures.java:102)
at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:868)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
at com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:105)
at com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:246)
at com.datastax.driver.core.RequestHandler.onSet(RequestHandler.java:278)
at com.datastax.driver.core.Connection$Dispatcher.messageReceived(Connection.java:661)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141225/2438d5cd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetResponseChannelAlreadyCallerError.zip
Type: application/zip
Size: 6572183 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20141225/2438d5cd/attachment-0001.zip