From sdouglas at redhat.com  Mon Jun  1 03:14:17 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 1 Jun 2015 03:14:17 -0400 (EDT)
Subject: [undertow-dev] Server-Sent Event and HttpServerExchange
In-Reply-To: <CAO+25pVoFypnJrTRhPvQTwJiyf6S3qmvLSi9n1zM7qqRWNvXEg@mail.gmail.com>
References: <CAO+25pVoFypnJrTRhPvQTwJiyf6S3qmvLSi9n1zM7qqRWNvXEg@mail.gmail.com>
Message-ID: <540101821.8986542.1433142857731.JavaMail.zimbra@redhat.com>

This was basically an oversight on my part. I have fixed this in Undertow upstream:

https://github.com/undertow-io/undertow/commit/90789748d3b493d7a233a4ef5ba8ae33032c1543

Stuart

----- Original Message -----
> From: "C?dric Tran-Xuan" <cedric.tranxuan at motwin.com>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 22 May, 2015 10:52:36 AM
> Subject: [undertow-dev] Server-Sent Event and HttpServerExchange
> 
> Hello,
> We are looking at the recent support of Server-Sent Events in Undertow, which
> looks great!
> 
> We are using the HttpServerExchange to pass data through different handlers
> (we do it by passing these data via setting Attachments to the
> HttpServerExchange). Ultimately, we need these data, to determine what to
> push to the client via SSE. And as we don't have access to the
> HttpServerExchange from the ServerSentEventConnection, we are a bit stuck.
> 
> We imagine we can code some ? hack ? to do so, but first, we were wondering
> if ever the dev team had some insights that could help us to implement the
> best solution that fits the ? Undertow spirit ? and our need.
> 
> Thanks in advance for your answer.
> Best regards,
> 
> C?dric.
> 
> PS: may be passing data via Attachments of HttpServerExchange is not the best
> practice?
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Mon Jun  1 03:15:43 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 1 Jun 2015 03:15:43 -0400 (EDT)
Subject: [undertow-dev] A question about response body size limit in
 undertow
In-Reply-To: <CAMPuLfjfLzQUPTdwT3nN3nQk17XE_2OvR-CxCK=pWw0hvdaDYA@mail.gmail.com>
References: <CAMPuLfjfLzQUPTdwT3nN3nQk17XE_2OvR-CxCK=pWw0hvdaDYA@mail.gmail.com>
Message-ID: <193958281.8986987.1433142943295.JavaMail.zimbra@redhat.com>

There are definitely no limits out of the box. How are you sending the data (streams, channels, or the Sender)?

Stuart

----- Original Message -----
> From: "adi amir" <adiamirg at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 27 May, 2015 10:46:07 AM
> Subject: [undertow-dev] A question about response body size limit in undertow
> 
> Hello
> 
> I'm working with undertow.
> I would appreciate help regarding the following issue:
> 
> I have a response that have a large body size (about 1.8MB).
> It seems that the undertow truncates the response after 100,000~ bytes.
> I could not find any configuration parameter to increases this limit nor
> a method to overcome this issue.
> 
> I would appreciate some tips on this issue.
> Thank you
> Adi Amir
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Mon Jun  1 03:19:02 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 1 Jun 2015 03:19:02 -0400 (EDT)
Subject: [undertow-dev] Server-Sent Event and HttpServerExchange
In-Reply-To: <540101821.8986542.1433142857731.JavaMail.zimbra@redhat.com>
References: <CAO+25pVoFypnJrTRhPvQTwJiyf6S3qmvLSi9n1zM7qqRWNvXEg@mail.gmail.com>
	<540101821.8986542.1433142857731.JavaMail.zimbra@redhat.com>
Message-ID: <173491357.8987525.1433143142162.JavaMail.zimbra@redhat.com>

Oops, that commit should have been https://github.com/undertow-io/undertow/commit/5bbab054a13e2fe05894be4d9fa37bc9476848ad

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "C?dric Tran-Xuan" <cedric.tranxuan at motwin.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 1 June, 2015 9:14:17 AM
> Subject: Re: [undertow-dev] Server-Sent Event and HttpServerExchange
> 
> This was basically an oversight on my part. I have fixed this in Undertow
> upstream:
> 
> https://github.com/undertow-io/undertow/commit/90789748d3b493d7a233a4ef5ba8ae33032c1543
> 
> Stuart
> 
> ----- Original Message -----
> > From: "C?dric Tran-Xuan" <cedric.tranxuan at motwin.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Friday, 22 May, 2015 10:52:36 AM
> > Subject: [undertow-dev] Server-Sent Event and HttpServerExchange
> > 
> > Hello,
> > We are looking at the recent support of Server-Sent Events in Undertow,
> > which
> > looks great!
> > 
> > We are using the HttpServerExchange to pass data through different handlers
> > (we do it by passing these data via setting Attachments to the
> > HttpServerExchange). Ultimately, we need these data, to determine what to
> > push to the client via SSE. And as we don't have access to the
> > HttpServerExchange from the ServerSentEventConnection, we are a bit stuck.
> > 
> > We imagine we can code some ? hack ? to do so, but first, we were wondering
> > if ever the dev team had some insights that could help us to implement the
> > best solution that fits the ? Undertow spirit ? and our need.
> > 
> > Thanks in advance for your answer.
> > Best regards,
> > 
> > C?dric.
> > 
> > PS: may be passing data via Attachments of HttpServerExchange is not the
> > best
> > practice?
> > 
> > _______________________________________________
> > 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


From cedric.tranxuan at motwin.com  Mon Jun  1 04:00:23 2015
From: cedric.tranxuan at motwin.com (=?UTF-8?Q?C=C3=A9dric_Tran=2DXuan?=)
Date: Mon, 1 Jun 2015 10:00:23 +0200
Subject: [undertow-dev] Server-Sent Event and HttpServerExchange
In-Reply-To: <173491357.8987525.1433143142162.JavaMail.zimbra@redhat.com>
References: <CAO+25pVoFypnJrTRhPvQTwJiyf6S3qmvLSi9n1zM7qqRWNvXEg@mail.gmail.com>
	<540101821.8986542.1433142857731.JavaMail.zimbra@redhat.com>
	<173491357.8987525.1433143142162.JavaMail.zimbra@redhat.com>
Message-ID: <CAO+25pWxVL=bzTsva9pkkCLm5O9LY781G3eDC+cqBZDi8ezPrg@mail.gmail.com>

Thanks for the commit! That will helps us for our devs!
Thanks again!

C?dric.

On Mon, Jun 1, 2015 at 9:19 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Oops, that commit should have been
> https://github.com/undertow-io/undertow/commit/5bbab054a13e2fe05894be4d9fa37bc9476848ad
>
> Stuart
>
> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "C?dric Tran-Xuan" <cedric.tranxuan at motwin.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, 1 June, 2015 9:14:17 AM
> > Subject: Re: [undertow-dev] Server-Sent Event and HttpServerExchange
> >
> > This was basically an oversight on my part. I have fixed this in Undertow
> > upstream:
> >
> >
> https://github.com/undertow-io/undertow/commit/90789748d3b493d7a233a4ef5ba8ae33032c1543
> >
> > Stuart
> >
> > ----- Original Message -----
> > > From: "C?dric Tran-Xuan" <cedric.tranxuan at motwin.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Friday, 22 May, 2015 10:52:36 AM
> > > Subject: [undertow-dev] Server-Sent Event and HttpServerExchange
> > >
> > > Hello,
> > > We are looking at the recent support of Server-Sent Events in Undertow,
> > > which
> > > looks great!
> > >
> > > We are using the HttpServerExchange to pass data through different
> handlers
> > > (we do it by passing these data via setting Attachments to the
> > > HttpServerExchange). Ultimately, we need these data, to determine what
> to
> > > push to the client via SSE. And as we don't have access to the
> > > HttpServerExchange from the ServerSentEventConnection, we are a bit
> stuck.
> > >
> > > We imagine we can code some ? hack ? to do so, but first, we were
> wondering
> > > if ever the dev team had some insights that could help us to implement
> the
> > > best solution that fits the ? Undertow spirit ? and our need.
> > >
> > > Thanks in advance for your answer.
> > > Best regards,
> > >
> > > C?dric.
> > >
> > > PS: may be passing data via Attachments of HttpServerExchange is not
> the
> > > best
> > > practice?
> > >
> > > _______________________________________________
> > > 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/20150601/00682d84/attachment.html 

From adiamirg at gmail.com  Mon Jun  1 06:30:11 2015
From: adiamirg at gmail.com (adi amir)
Date: Mon, 1 Jun 2015 13:30:11 +0300
Subject: [undertow-dev] A question about response body size limit in
	undertow
In-Reply-To: <193958281.8986987.1433142943295.JavaMail.zimbra@redhat.com>
References: <CAMPuLfjfLzQUPTdwT3nN3nQk17XE_2OvR-CxCK=pWw0hvdaDYA@mail.gmail.com>
	<193958281.8986987.1433142943295.JavaMail.zimbra@redhat.com>
Message-ID: <CAMPuLfgZNUwdxxrb13ciFGicsyOVfG6=tMxwraG9jOOUJJRa1g@mail.gmail.com>

it seems we didn't work properly with async mode.
its not a problem of response limit.
Now we are ok.
thanks.

On Mon, Jun 1, 2015 at 10:15 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> There are definitely no limits out of the box. How are you sending the
> data (streams, channels, or the Sender)?
>
> Stuart
>
> ----- Original Message -----
> > From: "adi amir" <adiamirg at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 27 May, 2015 10:46:07 AM
> > Subject: [undertow-dev] A question about response body size limit in
> undertow
> >
> > Hello
> >
> > I'm working with undertow.
> > I would appreciate help regarding the following issue:
> >
> > I have a response that have a large body size (about 1.8MB).
> > It seems that the undertow truncates the response after 100,000~ bytes.
> > I could not find any configuration parameter to increases this limit nor
> > a method to overcome this issue.
> >
> > I would appreciate some tips on this issue.
> > Thank you
> > Adi Amir
> >
> > _______________________________________________
> > 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/20150601/7307af4b/attachment.html 

From marc.boorshtein at tremolosecurity.com  Tue Jun  2 07:59:00 2015
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Tue, 2 Jun 2015 07:59:00 -0400
Subject: [undertow-dev] Stand alone undertow or undertow docker image?
Message-ID: <CAH2S7UDn=AOg2NRc0hrgvEQjwZ+gv2Z22tBHLxsCYOLtoyTA0g@mail.gmail.com>

Are there any plans for a stand alone undertow distro?  Or even better
has anyone put together an undertow docker image?

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
(703) 828-4902

From greg.hellings at gmail.com  Tue Jun  2 08:02:43 2015
From: greg.hellings at gmail.com (Greg Hellings)
Date: Tue, 2 Jun 2015 07:02:43 -0500
Subject: [undertow-dev] Stand alone undertow or undertow docker image?
In-Reply-To: <CAH2S7UDn=AOg2NRc0hrgvEQjwZ+gv2Z22tBHLxsCYOLtoyTA0g@mail.gmail.com>
References: <CAH2S7UDn=AOg2NRc0hrgvEQjwZ+gv2Z22tBHLxsCYOLtoyTA0g@mail.gmail.com>
Message-ID: <CAHxvOVJMy7MG1veCGAGTumd8ouZ+3K7iABCcZkfohvAgywnZqw@mail.gmail.com>

What exactly would an undertow distro/docker image have? Seems like any
base distro with java and maven installed would do the trick.
On Jun 2, 2015 6:59 AM, "Marc Boorshtein" <
marc.boorshtein at tremolosecurity.com> wrote:

> Are there any plans for a stand alone undertow distro?  Or even better
> has anyone put together an undertow docker image?
>
> Thanks
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> (703) 828-4902
> _______________________________________________
> 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/20150602/80c018e7/attachment-0001.html 

From michael.hixson at gmail.com  Tue Jun  2 19:13:24 2015
From: michael.hixson at gmail.com (Michael Hixson)
Date: Tue, 2 Jun 2015 16:13:24 -0700
Subject: [undertow-dev] http/2 server starts dying after rapid refresh
In-Reply-To: <CAHqckpMDijbTZmqwi8VB8NrhqEeDy3BTWXxs+13Q9nKQG_VPxg@mail.gmail.com>
References: <CAHqckpPfOO8tVprs9mxm_Bdd5K86wFTU5Ztt29jWfoNG2R-89A@mail.gmail.com>
	<4EA9BD5A-06AB-4828-ACF1-C5959EBA75BF@redhat.com>
	<CAHqckpOS_Ng4P=MRbLZenCGnNg9TmAx4=vbd=aCBfcYpDK4Q1g@mail.gmail.com>
	<CAHqckpMDijbTZmqwi8VB8NrhqEeDy3BTWXxs+13Q9nKQG_VPxg@mail.gmail.com>
Message-ID: <CAHqckpO_+OPz+XJumsChjZrg3r+ABKw0CMfAH6VfvBRAHFTOyA@mail.gmail.com>

Was this Jira issue 461?  I'm seeing promising results with this
commit, while if I revert the commit I run into the issue again.
https://github.com/undertow-io/undertow/commit/8f8e1658c5aface7f65a351e985d40c386a3f99b

If so, thanks!

-Michael

On Fri, May 29, 2015 at 10:26 PM, Michael Hixson
<michael.hixson at gmail.com> wrote:
> Also here is a jmap -histo from a little later:
> https://gist.github.com/michaelhixson/de6ede25fdb79a4f25b4
>
> (apologies in advance if gmail sends this email twice like my last one)
>
> -Michael
>
> On Fri, May 29, 2015 at 10:04 PM, Michael Hixson
> <michael.hixson at gmail.com> wrote:
>> Hi Jason,
>>
>> I believe the close() call is coming from me declaring the writer in a
>> try-with-resources statement.
>>
>> Here's a jstack from just now, where my CPU is sitting at 96%:
>> https://gist.github.com/michaelhixson/8a6f2ebf4b167fb1b67e
>>
>> -Michael
>>
>> On Fri, May 29, 2015 at 9:28 PM, Jason T. Greene
>> <jason.greene at redhat.com> wrote:
>>> Hi Michael,
>>>
>>> That stack trace seems to show a close() call to the writer in your handler, but I don't see that call in the code?
>>>
>>> Note that getting I/o exceptions during write and close calls is normal after a client abnormally terminates. You typically just drop the exception (perhaps trace logging).
>>>
>>> Could you get a jstack output under the scenario where you see high CPU load?
>>>
>>>
>>>> On May 28, 2015, at 6:19 PM, Michael Hixson <michael.hixson at gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm trying out HTTP/2 with undertow-core in my application, and I see
>>>> that I'm able to get the server into a bad state pretty reliably by
>>>> refreshing quickly in my browser.  It stops responding to requests and
>>>> the CPU usage of the Java process starts to climb towards 100%.
>>>>
>>>> I was able to replicate this in the HTTP/2 example in the latest from
>>>> the master branch, by changing the main HttpHandler.  This is what I
>>>> put in Http2Server#main(String[]):
>>>>
>>>>  Undertow server = Undertow.builder()
>>>>        .setServerOption(UndertowOptions.ENABLE_HTTP2, true)
>>>>        .setServerOption(UndertowOptions.ENABLE_SPDY, true)
>>>>        .addHttpListener(8080, bindAddress)
>>>>        .addHttpsListener(8443, bindAddress, sslContext)
>>>>        .setHandler(new HttpHandler() {
>>>>          @Override
>>>>          public void handleRequest(HttpServerExchange exchange) {
>>>>            if (exchange.isInIoThread()) {
>>>>              exchange.dispatch(this);
>>>>              return;
>>>>            }
>>>>            exchange.startBlocking();
>>>>            exchange.getResponseHeaders().put(
>>>>                new HttpString("Content-Type"), "text/html");
>>>>            try (BufferedWriter writer = new BufferedWriter(
>>>>                new OutputStreamWriter(
>>>>                    exchange.getOutputStream(),
>>>>                    StandardCharsets.UTF_8))) {
>>>>              writer.append("<!DOCTYPE html><html>\n");
>>>>              for (int i = 0; i < 100; i++) {
>>>>                writer.append(
>>>>                    "<link rel=\"stylesheet\" href=\"/" + i + ".css\">\n");
>>>>              }
>>>>              writer.append("hello");
>>>>            } catch (IOException e) {
>>>>              e.printStackTrace();
>>>>              throw new RuntimeException(e);
>>>>            }
>>>>          }
>>>>        }).build();
>>>>
>>>> Then I go to https://localhost:8443/ in a browser and hold down F5 for
>>>> a bit.  I start seeing errors like this:
>>>>
>>>>  java.nio.channels.ClosedChannelException
>>>>        at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.write(AbstractFramedStreamSinkChannel.java:396)
>>>>        at org.xnio.channels.Channels.writeFinalBasic(Channels.java:961)
>>>>        at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.writeFinal(AbstractFramedStreamSinkChannel.java:420)
>>>>        at org.xnio.conduits.StreamSinkChannelWrappingConduit.writeFinal(StreamSinkChannelWrappingConduit.java:66)
>>>>        at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104)
>>>>        at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:195)
>>>>        at io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1882)
>>>>        at io.undertow.io.UndertowOutputStream.writeBufferBlocking(UndertowOutputStream.java:288)
>>>>        at io.undertow.io.UndertowOutputStream.close(UndertowOutputStream.java:331)
>>>>        at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
>>>>        at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
>>>>        at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
>>>>        at java.io.BufferedWriter.close(BufferedWriter.java:266)
>>>>        at io.undertow.examples.http2.Http2Server$1.handleRequest(Http2Server.java:94)
>>>>        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>>>        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>>>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>>        at java.lang.Thread.run(Thread.java:745)
>>>>
>>>> In case it helps, I saw a different error in my real (not undertow
>>>> example) application when I started seeing the same effects visibly
>>>> (site down and CPU climbing to 100%).  Maybe it is the same root cause
>>>> but just being caught/logged differently:
>>>>
>>>>  ERROR [2015-05-28 14:23:59,804] org.xnio.nio: XNIO000011: Task
>>>> io.undertow.server.protocol.framed.AbstractFramedChannel$2 at 308b5f1f
>>>> failed with an exception
>>>>  java.lang.IllegalStateException: null
>>>>  at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:523)
>>>> ~[undertow-core-1.3.0.Beta1-SNAPSHOT.jar:1.3.0.Beta1-SNAPSHOT]
>>>>  at io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:496)
>>>> ~[undertow-core-1.3.0.Beta1-SNAPSHOT.jar:1.3.0.Beta1-SNAPSHOT]
>>>>  at io.undertow.server.protocol.framed.AbstractFramedChannel$2.run(AbstractFramedChannel.java:581)
>>>> ~[undertow-core-1.3.0.Beta1-SNAPSHOT.jar:1.3.0.Beta1-SNAPSHOT]
>>>>  at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
>>>> ~[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
>>>> ~[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
>>>>
>>>> I see the same behavior in my real application with both undertow-core
>>>> 1.2.6.Final and 1.3.0.Beta1-SNAPSHOT (the latter installed locally
>>>> from source).  I only tried the Http2Server example in the latest
>>>> version though.
>>>>
>>>> -Michael
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev

From michael.hixson at gmail.com  Wed Jun  3 00:17:40 2015
From: michael.hixson at gmail.com (Michael Hixson)
Date: Tue, 2 Jun 2015 21:17:40 -0700
Subject: [undertow-dev] nghttp2 requests to Undertow - "[ERROR] HTTP/2
 protocol was not selected. (nghttp2 expects h2)"
Message-ID: <CAHqckpM5zBgA13uPZzJZ2_Co6hmH68J32e6nWMTwRqL0Zzu5DA@mail.gmail.com>

I am attempting to make requests to an Undertow+HTTP/2 server with nghttp2.

https://github.com/tatsuhiro-t/nghttp2

The requests fail.  I see the same error on the public demo site for
Undertow+HTTP/2, and I don't see any errors when I hit other
HTTP/2-enabled public sites, such as google.com.

The error is "[ERROR] HTTP/2 protocol was not selected. (nghttp2
expects h2)".  See the end of this email for full output from the
command line for requests to google.com and http2.undertow.io.

I'm wondering if this is a bug in Undertow.  Or perhaps it is a bug in
nghttp2 and I'm on the wrong mailing list.  Have any of you tried
this?  Any thoughts?

I'm using nghttp2 version 1.1.  The Undertow version is whatever the
public demo site is running right now, but I also tried it locally
with the latest from master (1.3.0.Beta1-SNAPSHOT) and got the same
result.

-Michael


----------------------------------------------


$ nghttp -ns https://www.google.com/
***** Statistics *****

Request timing:
  responseEnd: the  time  when  last  byte of  response  was  received
               relative to connectEnd
 requestStart: the time  just before  first byte  of request  was sent
               relative  to connectEnd.   If  '*' is  shown, this  was
               pushed by server.
      process: responseEnd - requestStart
         code: HTTP status code
         size: number  of  bytes  received as  response  body  without
               inflation.
          URI: request URI

see http://www.w3.org/TR/resource-timing/#processing-model

sorted by 'complete'

id  responseEnd requestStart  process code size request path
 13    +83.40ms       +161us  83.24ms  200  19K /


----------------------------------------------


$ nghttp -ns https://http2.undertow.io/
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
Some requests were not processed. total=1, processed=0
***** Statistics *****

Request timing:
  responseEnd: the  time  when  last  byte of  response  was  received
               relative to connectEnd
 requestStart: the time  just before  first byte  of request  was sent
               relative  to connectEnd.   If  '*' is  shown, this  was
               pushed by server.
      process: responseEnd - requestStart
         code: HTTP status code
         size: number  of  bytes  received as  response  body  without
               inflation.
          URI: request URI

see http://www.w3.org/TR/resource-timing/#processing-model

sorted by 'complete'

id  responseEnd requestStart  process code size request path

From sdouglas at redhat.com  Wed Jun  3 03:36:28 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 3 Jun 2015 03:36:28 -0400 (EDT)
Subject: [undertow-dev] http/2 server starts dying after rapid refresh
In-Reply-To: <CAHqckpO_+OPz+XJumsChjZrg3r+ABKw0CMfAH6VfvBRAHFTOyA@mail.gmail.com>
References: <CAHqckpPfOO8tVprs9mxm_Bdd5K86wFTU5Ztt29jWfoNG2R-89A@mail.gmail.com>
	<4EA9BD5A-06AB-4828-ACF1-C5959EBA75BF@redhat.com>
	<CAHqckpOS_Ng4P=MRbLZenCGnNg9TmAx4=vbd=aCBfcYpDK4Q1g@mail.gmail.com>
	<CAHqckpMDijbTZmqwi8VB8NrhqEeDy3BTWXxs+13Q9nKQG_VPxg@mail.gmail.com>
	<CAHqckpO_+OPz+XJumsChjZrg3r+ABKw0CMfAH6VfvBRAHFTOyA@mail.gmail.com>
Message-ID: <679006218.11400496.1433316988107.JavaMail.zimbra@redhat.com>

https://github.com/undertow-io/undertow/commit/4cd914008fc7fddca97af5300523b96bba81d895

Is the one.

Stuart

----- Original Message -----
> From: "Michael Hixson" <michael.hixson at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 3 June, 2015 1:13:24 AM
> Subject: Re: [undertow-dev] http/2 server starts dying after rapid refresh
> 
> Was this Jira issue 461?  I'm seeing promising results with this
> commit, while if I revert the commit I run into the issue again.
> https://github.com/undertow-io/undertow/commit/8f8e1658c5aface7f65a351e985d40c386a3f99b
> 
> If so, thanks!
> 
> -Michael
> 
> On Fri, May 29, 2015 at 10:26 PM, Michael Hixson
> <michael.hixson at gmail.com> wrote:
> > Also here is a jmap -histo from a little later:
> > https://gist.github.com/michaelhixson/de6ede25fdb79a4f25b4
> >
> > (apologies in advance if gmail sends this email twice like my last one)
> >
> > -Michael
> >
> > On Fri, May 29, 2015 at 10:04 PM, Michael Hixson
> > <michael.hixson at gmail.com> wrote:
> >> Hi Jason,
> >>
> >> I believe the close() call is coming from me declaring the writer in a
> >> try-with-resources statement.
> >>
> >> Here's a jstack from just now, where my CPU is sitting at 96%:
> >> https://gist.github.com/michaelhixson/8a6f2ebf4b167fb1b67e
> >>
> >> -Michael
> >>
> >> On Fri, May 29, 2015 at 9:28 PM, Jason T. Greene
> >> <jason.greene at redhat.com> wrote:
> >>> Hi Michael,
> >>>
> >>> That stack trace seems to show a close() call to the writer in your
> >>> handler, but I don't see that call in the code?
> >>>
> >>> Note that getting I/o exceptions during write and close calls is normal
> >>> after a client abnormally terminates. You typically just drop the
> >>> exception (perhaps trace logging).
> >>>
> >>> Could you get a jstack output under the scenario where you see high CPU
> >>> load?
> >>>
> >>>
> >>>> On May 28, 2015, at 6:19 PM, Michael Hixson <michael.hixson at gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> I'm trying out HTTP/2 with undertow-core in my application, and I see
> >>>> that I'm able to get the server into a bad state pretty reliably by
> >>>> refreshing quickly in my browser.  It stops responding to requests and
> >>>> the CPU usage of the Java process starts to climb towards 100%.
> >>>>
> >>>> I was able to replicate this in the HTTP/2 example in the latest from
> >>>> the master branch, by changing the main HttpHandler.  This is what I
> >>>> put in Http2Server#main(String[]):
> >>>>
> >>>>  Undertow server = Undertow.builder()
> >>>>        .setServerOption(UndertowOptions.ENABLE_HTTP2, true)
> >>>>        .setServerOption(UndertowOptions.ENABLE_SPDY, true)
> >>>>        .addHttpListener(8080, bindAddress)
> >>>>        .addHttpsListener(8443, bindAddress, sslContext)
> >>>>        .setHandler(new HttpHandler() {
> >>>>          @Override
> >>>>          public void handleRequest(HttpServerExchange exchange) {
> >>>>            if (exchange.isInIoThread()) {
> >>>>              exchange.dispatch(this);
> >>>>              return;
> >>>>            }
> >>>>            exchange.startBlocking();
> >>>>            exchange.getResponseHeaders().put(
> >>>>                new HttpString("Content-Type"), "text/html");
> >>>>            try (BufferedWriter writer = new BufferedWriter(
> >>>>                new OutputStreamWriter(
> >>>>                    exchange.getOutputStream(),
> >>>>                    StandardCharsets.UTF_8))) {
> >>>>              writer.append("<!DOCTYPE html><html>\n");
> >>>>              for (int i = 0; i < 100; i++) {
> >>>>                writer.append(
> >>>>                    "<link rel=\"stylesheet\" href=\"/" + i +
> >>>>                    ".css\">\n");
> >>>>              }
> >>>>              writer.append("hello");
> >>>>            } catch (IOException e) {
> >>>>              e.printStackTrace();
> >>>>              throw new RuntimeException(e);
> >>>>            }
> >>>>          }
> >>>>        }).build();
> >>>>
> >>>> Then I go to https://localhost:8443/ in a browser and hold down F5 for
> >>>> a bit.  I start seeing errors like this:
> >>>>
> >>>>  java.nio.channels.ClosedChannelException
> >>>>        at
> >>>>        io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.write(AbstractFramedStreamSinkChannel.java:396)
> >>>>        at org.xnio.channels.Channels.writeFinalBasic(Channels.java:961)
> >>>>        at
> >>>>        io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.writeFinal(AbstractFramedStreamSinkChannel.java:420)
> >>>>        at
> >>>>        org.xnio.conduits.StreamSinkChannelWrappingConduit.writeFinal(StreamSinkChannelWrappingConduit.java:66)
> >>>>        at
> >>>>        org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104)
> >>>>        at
> >>>>        io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:195)
> >>>>        at
> >>>>        io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1882)
> >>>>        at
> >>>>        io.undertow.io.UndertowOutputStream.writeBufferBlocking(UndertowOutputStream.java:288)
> >>>>        at
> >>>>        io.undertow.io.UndertowOutputStream.close(UndertowOutputStream.java:331)
> >>>>        at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
> >>>>        at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
> >>>>        at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
> >>>>        at java.io.BufferedWriter.close(BufferedWriter.java:266)
> >>>>        at
> >>>>        io.undertow.examples.http2.Http2Server$1.handleRequest(Http2Server.java:94)
> >>>>        at
> >>>>        io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> >>>>        at
> >>>>        io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> >>>>        at
> >>>>        java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >>>>        at
> >>>>        java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >>>>        at java.lang.Thread.run(Thread.java:745)
> >>>>
> >>>> In case it helps, I saw a different error in my real (not undertow
> >>>> example) application when I started seeing the same effects visibly
> >>>> (site down and CPU climbing to 100%).  Maybe it is the same root cause
> >>>> but just being caught/logged differently:
> >>>>
> >>>>  ERROR [2015-05-28 14:23:59,804] org.xnio.nio: XNIO000011: Task
> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$2 at 308b5f1f
> >>>> failed with an exception
> >>>>  java.lang.IllegalStateException: null
> >>>>  at
> >>>>  io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:523)
> >>>> ~[undertow-core-1.3.0.Beta1-SNAPSHOT.jar:1.3.0.Beta1-SNAPSHOT]
> >>>>  at
> >>>>  io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:496)
> >>>> ~[undertow-core-1.3.0.Beta1-SNAPSHOT.jar:1.3.0.Beta1-SNAPSHOT]
> >>>>  at
> >>>>  io.undertow.server.protocol.framed.AbstractFramedChannel$2.run(AbstractFramedChannel.java:581)
> >>>> ~[undertow-core-1.3.0.Beta1-SNAPSHOT.jar:1.3.0.Beta1-SNAPSHOT]
> >>>>  at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> >>>> ~[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
> >>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> >>>> ~[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
> >>>>
> >>>> I see the same behavior in my real application with both undertow-core
> >>>> 1.2.6.Final and 1.3.0.Beta1-SNAPSHOT (the latter installed locally
> >>>> from source).  I only tried the Http2Server example in the latest
> >>>> version though.
> >>>>
> >>>> -Michael
> >>>> _______________________________________________
> >>>> 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
> 

From sdouglas at redhat.com  Wed Jun  3 03:56:43 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 3 Jun 2015 03:56:43 -0400 (EDT)
Subject: [undertow-dev] nghttp2 requests to Undertow - "[ERROR] HTTP/2
 protocol was not selected. (nghttp2 expects h2)"
In-Reply-To: <CAHqckpM5zBgA13uPZzJZ2_Co6hmH68J32e6nWMTwRqL0Zzu5DA@mail.gmail.com>
References: <CAHqckpM5zBgA13uPZzJZ2_Co6hmH68J32e6nWMTwRqL0Zzu5DA@mail.gmail.com>
Message-ID: <1228481873.11441019.1433318203844.JavaMail.zimbra@redhat.com>

This is very odd. What version of OpenSSL do you have? From their docs:

"ALPN support requires OpenSSL >= 1.0.2 (released 22 January 2015)."

If you have an older version it will be using NPN (which was used by early drafts of the protocol), which we do not support. 

Stuart

----- Original Message -----
> From: "Michael Hixson" <michael.hixson at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 3 June, 2015 6:17:40 AM
> Subject: [undertow-dev] nghttp2 requests to Undertow - "[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects
> h2)"
> 
> I am attempting to make requests to an Undertow+HTTP/2 server with nghttp2.
> 
> https://github.com/tatsuhiro-t/nghttp2
> 
> The requests fail.  I see the same error on the public demo site for
> Undertow+HTTP/2, and I don't see any errors when I hit other
> HTTP/2-enabled public sites, such as google.com.
> 
> The error is "[ERROR] HTTP/2 protocol was not selected. (nghttp2
> expects h2)".  See the end of this email for full output from the
> command line for requests to google.com and http2.undertow.io.
> 
> I'm wondering if this is a bug in Undertow.  Or perhaps it is a bug in
> nghttp2 and I'm on the wrong mailing list.  Have any of you tried
> this?  Any thoughts?
> 
> I'm using nghttp2 version 1.1.  The Undertow version is whatever the
> public demo site is running right now, but I also tried it locally
> with the latest from master (1.3.0.Beta1-SNAPSHOT) and got the same
> result.
> 
> -Michael
> 
> 
> ----------------------------------------------
> 
> 
> $ nghttp -ns https://www.google.com/
> ***** Statistics *****
> 
> Request timing:
>   responseEnd: the  time  when  last  byte of  response  was  received
>                relative to connectEnd
>  requestStart: the time  just before  first byte  of request  was sent
>                relative  to connectEnd.   If  '*' is  shown, this  was
>                pushed by server.
>       process: responseEnd - requestStart
>          code: HTTP status code
>          size: number  of  bytes  received as  response  body  without
>                inflation.
>           URI: request URI
> 
> see http://www.w3.org/TR/resource-timing/#processing-model
> 
> sorted by 'complete'
> 
> id  responseEnd requestStart  process code size request path
>  13    +83.40ms       +161us  83.24ms  200  19K /
> 
> 
> ----------------------------------------------
> 
> 
> $ nghttp -ns https://http2.undertow.io/
> [ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
> Some requests were not processed. total=1, processed=0
> ***** Statistics *****
> 
> Request timing:
>   responseEnd: the  time  when  last  byte of  response  was  received
>                relative to connectEnd
>  requestStart: the time  just before  first byte  of request  was sent
>                relative  to connectEnd.   If  '*' is  shown, this  was
>                pushed by server.
>       process: responseEnd - requestStart
>          code: HTTP status code
>          size: number  of  bytes  received as  response  body  without
>                inflation.
>           URI: request URI
> 
> see http://www.w3.org/TR/resource-timing/#processing-model
> 
> sorted by 'complete'
> 
> id  responseEnd requestStart  process code size request path
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From michael.hixson at gmail.com  Wed Jun  3 17:35:40 2015
From: michael.hixson at gmail.com (Michael Hixson)
Date: Wed, 3 Jun 2015 14:35:40 -0700
Subject: [undertow-dev] nghttp2 requests to Undertow - "[ERROR] HTTP/2
 protocol was not selected. (nghttp2 expects h2)"
In-Reply-To: <1228481873.11441019.1433318203844.JavaMail.zimbra@redhat.com>
References: <CAHqckpM5zBgA13uPZzJZ2_Co6hmH68J32e6nWMTwRqL0Zzu5DA@mail.gmail.com>
	<1228481873.11441019.1433318203844.JavaMail.zimbra@redhat.com>
Message-ID: <CAHqckpMi7ixE04fJs9o6Bc5e2HZwvTzjVf3vU9oHMohOwOUObg@mail.gmail.com>

Yeah that must be it.  Thanks, Stuart.

-Michael

On Wed, Jun 3, 2015 at 12:56 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
> This is very odd. What version of OpenSSL do you have? From their docs:
>
> "ALPN support requires OpenSSL >= 1.0.2 (released 22 January 2015)."
>
> If you have an older version it will be using NPN (which was used by early drafts of the protocol), which we do not support.
>
> Stuart
>
> ----- Original Message -----
>> From: "Michael Hixson" <michael.hixson at gmail.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Wednesday, 3 June, 2015 6:17:40 AM
>> Subject: [undertow-dev] nghttp2 requests to Undertow - "[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects
>> h2)"
>>
>> I am attempting to make requests to an Undertow+HTTP/2 server with nghttp2.
>>
>> https://github.com/tatsuhiro-t/nghttp2
>>
>> The requests fail.  I see the same error on the public demo site for
>> Undertow+HTTP/2, and I don't see any errors when I hit other
>> HTTP/2-enabled public sites, such as google.com.
>>
>> The error is "[ERROR] HTTP/2 protocol was not selected. (nghttp2
>> expects h2)".  See the end of this email for full output from the
>> command line for requests to google.com and http2.undertow.io.
>>
>> I'm wondering if this is a bug in Undertow.  Or perhaps it is a bug in
>> nghttp2 and I'm on the wrong mailing list.  Have any of you tried
>> this?  Any thoughts?
>>
>> I'm using nghttp2 version 1.1.  The Undertow version is whatever the
>> public demo site is running right now, but I also tried it locally
>> with the latest from master (1.3.0.Beta1-SNAPSHOT) and got the same
>> result.
>>
>> -Michael
>>
>>
>> ----------------------------------------------
>>
>>
>> $ nghttp -ns https://www.google.com/
>> ***** Statistics *****
>>
>> Request timing:
>>   responseEnd: the  time  when  last  byte of  response  was  received
>>                relative to connectEnd
>>  requestStart: the time  just before  first byte  of request  was sent
>>                relative  to connectEnd.   If  '*' is  shown, this  was
>>                pushed by server.
>>       process: responseEnd - requestStart
>>          code: HTTP status code
>>          size: number  of  bytes  received as  response  body  without
>>                inflation.
>>           URI: request URI
>>
>> see http://www.w3.org/TR/resource-timing/#processing-model
>>
>> sorted by 'complete'
>>
>> id  responseEnd requestStart  process code size request path
>>  13    +83.40ms       +161us  83.24ms  200  19K /
>>
>>
>> ----------------------------------------------
>>
>>
>> $ nghttp -ns https://http2.undertow.io/
>> [ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
>> Some requests were not processed. total=1, processed=0
>> ***** Statistics *****
>>
>> Request timing:
>>   responseEnd: the  time  when  last  byte of  response  was  received
>>                relative to connectEnd
>>  requestStart: the time  just before  first byte  of request  was sent
>>                relative  to connectEnd.   If  '*' is  shown, this  was
>>                pushed by server.
>>       process: responseEnd - requestStart
>>          code: HTTP status code
>>          size: number  of  bytes  received as  response  body  without
>>                inflation.
>>           URI: request URI
>>
>> see http://www.w3.org/TR/resource-timing/#processing-model
>>
>> sorted by 'complete'
>>
>> id  responseEnd requestStart  process code size request path
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>

From gpn at networkart.com  Thu Jun  4 15:21:44 2015
From: gpn at networkart.com (Guruprasad Nagaraj)
Date: Thu, 4 Jun 2015 19:21:44 +0000
Subject: [undertow-dev] Websocket: onMessage() called prior to onOpen()
Message-ID: <9515CC40-AE17-4461-9DEB-25ABAB7F6837@networkart.com>

Wildfly version: 8.2.0.Final
Undertow version: 1.1.0.Final

Hi,
I am using Undertow web sockets.
A remote client (nopoll c client) attempts to open a websocket session; the session is opened and the client immediately sends a message.
However, at the ServerEndpoint, the onMessage handler is called prior to the onOpen handler.
My server side implementation rejects messages received prior to open and even forces a session close.
The client retries the session, and sometimes it is successful i.e. I do see an open first and then followed by a message by the client.

Is this an known issue?
Sorry, I couldn?t find a way to search the mailing-list archives.

Thanks and Best Regards,
GPN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150604/87ab4c41/attachment.html 

From jasipher at gmail.com  Thu Jun  4 14:06:26 2015
From: jasipher at gmail.com (John Sipher)
Date: Thu, 4 Jun 2015 14:06:26 -0400
Subject: [undertow-dev] Undertow doesn't write cookie to response
Message-ID: <CAGXQejMU8fMzjAOM0khp4Q8y2XCE-e1hj2+Q0-dk6+NJp97xMw@mail.gmail.com>

Copy/pasted from
https://developer.jboss.org/message/932789?et=watches.email.thread#932789.
Any help would be appreciated...



I'm trying to migrate an application from JBoss 7,.2.0.Final to WildFly
8.2.0.Final, and I find that some cookies are not written to the servlet
response. I've tracked it down to
io.undertow.servlet.spec.HttpServletResponseImpl.addCookie().



   1.     @Override
   2.     public void addCookie(final Cookie cookie) {
   3.         if (insideInclude) {
   4.             return;
   5.         }
   6.         final ServletCookieAdaptor servletCookieAdaptor = new
    ServletCookieAdaptor(cookie);
   7.         if (cookie.getVersion() == 0) {
   8.
               servletCookieAdaptor.setVersion(servletContext.getDeployment().getDeploymentInfo().getDefaultCookieVersion());
   9.         }
   10.         exchange.setResponseCookie(servletCookieAdaptor);
   11.     }



Apparently the insideCookie flag has been set to true at the point we're
calling HttpServletResponse.addCookie(), so WildFly/Undertow just quietly
throws it away and leaves me scratching my head trying to figure out what
went wrong.



When I search back up the call stack I see that our servlet is including a
JSP page in its response like this



   1.
                   RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(page);
   2.
                   dispatcher.include(state.getRequest(),
state.getResponse());



So, it makes sense that insideInclude is true, since the code that's trying
to set the cookie is being called from inside RequestDispatcher.include(),
but I don't understand why WildFly/Undertow just arbitrarily throws it away.
- See more at:
https://developer.jboss.org/message/932789?et=watches.email.thread#932789
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150604/e47c6a90/attachment-0001.html 

From sdouglas at redhat.com  Fri Jun  5 01:32:19 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 5 Jun 2015 01:32:19 -0400 (EDT)
Subject: [undertow-dev] Undertow doesn't write cookie to response
In-Reply-To: <CAGXQejMU8fMzjAOM0khp4Q8y2XCE-e1hj2+Q0-dk6+NJp97xMw@mail.gmail.com>
References: <CAGXQejMU8fMzjAOM0khp4Q8y2XCE-e1hj2+Q0-dk6+NJp97xMw@mail.gmail.com>
Message-ID: <2099974823.13511989.1433482339946.JavaMail.zimbra@redhat.com>


>From the servlet spec (9.3) about includes:

It can only write information to the ServletOutputStream or Writer of the response object and commit a response by writing content past the end of the response buffer, or by explicitly calling the flushBuffer method of the ServletResponse interface. It cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest.getSession() and HttpServletRequest.getSession(boolean) methods.

As addCookie will modify the response headers, it is not allowed so we ignore it. 

Stuart


----- Original Message -----
> From: "John Sipher" <jasipher at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 4 June, 2015 8:06:26 PM
> Subject: [undertow-dev] Undertow doesn't write cookie to response
> 
> Copy/pasted from
> https://developer.jboss.org/message/932789?et=watches.email.thread#932789 .
> Any help would be appreciated...
> 
> 
> 
> 
> 
> I'm trying to migrate an application from JBoss 7,.2.0.Final to WildFly
> 8.2.0.Final, and I find that some cookies are not written to the servlet
> response. I've tracked it down to
> io.undertow.servlet.spec.HttpServletResponseImpl.addCookie().
> 
> 
> 
> 
>     1. @Override
>     2. public void addCookie( final Cookie cookie) {
>     3. if (insideInclude) {
>     4. return ;
>     5. }
>     6. final ServletCookieAdaptor servletCookieAdaptor = new
>     ServletCookieAdaptor(cookie);
>     7. if (cookie.getVersion() == 0 ) {
>     8.
>     servletCookieAdaptor.setVersion(servletContext.getDeployment().getDeploymentInfo().getDefaultCookieVersion());
>     9. }
>     10. exchange.setResponseCookie(servletCookieAdaptor);
>     11. }
> 
> 
> 
> 
> Apparently the insideCookie flag has been set to true at the point we're
> calling HttpServletResponse.addCookie(), so WildFly/Undertow just quietly
> throws it away and leaves me scratching my head trying to figure out what
> went wrong.
> 
> 
> 
> When I search back up the call stack I see that our servlet is including a
> JSP page in its response like this
> 
> 
> 
> 
>     1. RequestDispatcher dispatcher =
>     getServletContext().getRequestDispatcher(page);
>     2. dispatcher.include(state.getRequest(), state.getResponse());
> 
> 
> 
> 
> So, it makes sense that insideInclude is true, since the code that's trying
> to set the cookie is being called from inside RequestDispatcher.include(),
> but I don't understand why WildFly/Undertow just arbitrarily throws it away.
> - See more at:
> https://developer.jboss.org/message/932789?et=watches.email.thread#932789
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Fri Jun  5 01:42:08 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 05 Jun 2015 07:42:08 +0200
Subject: [undertow-dev] Websocket: onMessage() called prior to onOpen()
In-Reply-To: <9515CC40-AE17-4461-9DEB-25ABAB7F6837@networkart.com>
References: <9515CC40-AE17-4461-9DEB-25ABAB7F6837@networkart.com>
Message-ID: <557136B0.80203@redhat.com>

Do you have a way to reproduce this?

Stuart

Guruprasad Nagaraj wrote:
> Wildfly version: 8.2.0.Final
> Undertow version: 1.1.0.Final
>
> Hi,
> I am using Undertow web sockets.
> A remote client (nopoll c client) attempts to open a websocket session;
> the session is opened and the client immediately sends a message.
> However, at the ServerEndpoint, the onMessage handler is called prior to
> the onOpen handler.
> My server side implementation rejects messages received prior to open
> and even forces a session close.
> The client retries the session, and sometimes it is successful i.e. I do
> see an open first and then followed by a message by the client.
>
> Is this an known issue?
> Sorry, I couldn?t find a way to search the mailing-list archives.
>
> Thanks and Best Regards,
> GPN
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From gpn at networkart.com  Fri Jun  5 04:00:33 2015
From: gpn at networkart.com (Guruprasad Nagaraj)
Date: Fri, 5 Jun 2015 08:00:33 +0000
Subject: [undertow-dev] Websocket: onMessage() called prior to onOpen()
In-Reply-To: <557136B0.80203@redhat.com>
References: <9515CC40-AE17-4461-9DEB-25ABAB7F6837@networkart.com>
	<557136B0.80203@redhat.com>
Message-ID: <A40029DF-CBF4-48B2-A8A0-C19DFEF34983@networkart.com>

Hi Stuart,
Yes, indeed. I can reproduce this all the time.

Here is a snippet from the wildfly console log -

==== WILDFLY STARTUP ====
13:01:55,848 INFO  [io.undertow.websockets.jsr] (MSC service thread 1-1) UT026003: Adding annotated server endpoint class com.NetworkArt.SVCentral.web.server.ws.agent.am.AMChannel for path /channel/am

==== ON STARTING REMOTE WEBSOCKET CLIENT ====
13:02:39,512 WARN  [AMChannel] (default task-3) msgRx(session-id: WhXpPiKFnU0l1rAUXkWExfVc) AUTH_REQ received in an unknown session, discarding
13:02:39,513 INFO  [AMChannel] (default task-3) forceClose(session-id: WhXpPiKFnU0l1rAUXkWExfVc)
13:02:39,883 INFO  [AMChannel] (default task-2) [acme] open( session-id: WhXpPiKFnU0l1rAUXkWExfVc) Added session
13:02:39,884 INFO  [AMChannel] (default task-2) [acme] close(session-id: WhXpPiKFnU0l1rAUXkWExfVc)

AMChannel is the annotated server endpoint, with open() and msgRx() as the onOpen and onMessage handlers respectively.

@ServerEndpoint(value = SVUrls.SVURL_FRAG_WS_CHANNEL_AM,
                configurator = WsConfigurator.class,
                encoders = {AMMsgEncoder.class},
                decoders = {AMMsgDecoder.class})
public class AMChannel {
...
}

WsConfigurator allows me to extract the host part of the FQDN in the connection url. acme.networkart.com<http://acme.networkart.com> would be the FQDN and WsConfigurator allows me to extract ?acme? and put in the EndpointConfig userProperties.
AMMsgEncoder and AMMsgDecoder help in converting to an OutputStream and InputStream respectively.

session-id is the value retrieved from javax.websocket.Session getId().

AUTH_REQ is a message sent by the remote client post a successful connection with AMChannel.

forceClose() is a method in AMChannel that forces a session close. In the above snippet, as you see I am forcing a session close() since AMChannel hadn?t been called with open() earlier (which would be the point at which I would have recorded the session).

The remote client retries every 5 seconds post failure conditions. As I said earlier, some retries are again unsuccessful for the same reason, and sometimes they succeed.

I could put a workaround in the client to sleep for sometime before sending the first message to AMChannel, but I would like to see if the above issue can be solved before I do that.

Please let me know if you require any other information.

Thanks and Best Regards,
GPN

On 05-Jun-2015, at 11:12 am, Stuart Douglas <sdouglas at redhat.com<mailto:sdouglas at redhat.com>> wrote:

Do you have a way to reproduce this?

Stuart

Guruprasad Nagaraj wrote:
Wildfly version: 8.2.0.Final
Undertow version: 1.1.0.Final

Hi,
I am using Undertow web sockets.
A remote client (nopoll c client) attempts to open a websocket session;
the session is opened and the client immediately sends a message.
However, at the ServerEndpoint, the onMessage handler is called prior to
the onOpen handler.
My server side implementation rejects messages received prior to open
and even forces a session close.
The client retries the session, and sometimes it is successful i.e. I do
see an open first and then followed by a message by the client.

Is this an known issue?
Sorry, I couldn?t find a way to search the mailing-list archives.

Thanks and Best Regards,
GPN

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org<mailto: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/20150605/b44c1fb9/attachment-0001.html 

From anmiller at redhat.com  Mon Jun 15 13:29:46 2015
From: anmiller at redhat.com (Andrig T. Miller)
Date: Mon, 15 Jun 2015 13:29:46 -0400 (EDT)
Subject: [undertow-dev] Question about APR based connector in Undertow
In-Reply-To: <9469006.494.1434388988709.JavaMail.andrigtmiller@worklaptop.miller.org>
Message-ID: <24712864.506.1434389385027.JavaMail.andrigtmiller@worklaptop.miller.org>

I am hearing that some work is being put into an APR based connector for Undertow. I am wondering why we are doing this? 

Based on my own testing, and testing the performance team has done with AS 7.x/EAP 6.x/Wildfly, I see no performance reason to do it, and it creates more work for getting product out the door, and maintaining product. 

We have found that the APR based connector can exhibit very poor scalability, and consume large amounts of CPU resources when in a network environment that is having problems (TCP resets, dropped and retransmitted packets, etc.). 

In this situation, especially where we see these poor network conditions, the APR connector spends a lot of its time managing the connection data structure. That data structure is a ring (doubly linked list with head and tail pointing at each other, which you already know). That ring is sequentially searched for the socket to remove and it locks all access with a mutex before it does this. This causes both a CPU consumption issue, as it sequentially walks the linked list, and a blocking problem. When we first discovered this, I went into the code to see how easy it would be to change it. I don't think this is a simple fix, and since APR is the underpinning of other things, like Apache HTTPD, not a trivial thing to get accepted by the community either. This spurred us to look at the NIO2 based connector, which at the time was unsupported, and it didn't exhibit any of this poor behavior. That's what spurred the effort to move the NIO2 based connector to be fully supported. 

In the absence of poor network conditions, the APR connector behaves and performs well, but in the presence of poor network conditions its not good. So, with a viable alternative, which Undertow provides out of the box with its XNIO based architecture, there simple seems no good reason to do with for Undertow. 

Thanks. 

-- 

Andrig (Andy) T. Miller 
Global Platform Director, JBoss Middleware 
Red Hat, Inc. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150615/ec84ae84/attachment.html 

From jason.greene at redhat.com  Mon Jun 15 13:51:39 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 15 Jun 2015 12:51:39 -0500
Subject: [undertow-dev] Question about APR based connector in Undertow
In-Reply-To: <24712864.506.1434389385027.JavaMail.andrigtmiller@worklaptop.miller.org>
References: <24712864.506.1434389385027.JavaMail.andrigtmiller@worklaptop.miller.org>
Message-ID: <EF85EEF4-7CD8-44F1-90CF-0CB4E3DEAA28@redhat.com>

We have no intention to do an APR connector. We have had some occasional discussions about whether or not we will need openssl support. Perhaps that?s where it is coming from?

JFC and Remy had some numbers on JBossWeb that showed poor perf on JSSE vs OpenSSL using APR. It?s somewhat apples vs oranges but looking at the JSSE impl we do see a number of inefficiencies. As an example JSSE seems to do a lot of copying (e.g. anything in a buffer becomes many byte arrays which gets copied again to a buffer). We also see that SHA support on intel is still in a big chunk of java code, and not intrinsic, wheras on openssl its optimized assembler. The new AES GCM ciphers are also known to be slow, but Andrew Haley mentioned that he is in the process of optimizing those. All of this is of course, anecdotal, and until we spend some cycles doing a more apples to apples test I don?t think we can conclude this is a necessary direction.

The other case where this might matter is how we find a way to support HTTP2. HTTP2 requires that we support the ALPN extension to TLS. Unfortunately JSSE has no support for it, and has been rather slow to implement, and it has to come into 9 before there is any possibility of a backport to 8:

http://openjdk.java.net/jeps/244
https://bugs.openjdk.java.net/browse/JDK-8051498 <https://bugs.openjdk.java.net/browse/JDK-8051498>

In the meantime we have been reusing a hack that the Jetty guys are maintaining as a separate project, and it requires using bootclasspath to replace core JSSE classes. These hacks are not z-stream compatible, so any JDK bug fix update can break the hack (and this has already happened about 2-3 times).

So on that perspective we have three options:

1)  Red Hat does a Red Hat only hack for IcedTea distributions (not sure if the JDK team would be willing to maintain it or not, would have to ask)
2)  Introduce openssl support, which supports ALPN
3)  Wait for JSSE, and live with the hack (warning people appropriately)

At this point, I don?t think we can commit to having anything for the WildFly 10 schedule, unless the performance difference really mandates such a thing, and then we might have to shuffle things around. 

> On Jun 15, 2015, at 12:29 PM, Andrig T. Miller <anmiller at redhat.com> wrote:
> 
> I am hearing that some work is being put into an APR based connector for Undertow.  I am wondering why we are doing this?
> 
> Based on my own testing, and testing the performance team has done with AS 7.x/EAP 6.x/Wildfly, I see no performance reason to do it, and it creates more work for getting product out the door, and maintaining product.
> 
> We have found that the APR based connector can exhibit very poor scalability, and consume large amounts of CPU resources when in a network environment that is having problems (TCP resets, dropped and retransmitted packets, etc.).
> 
> In this situation, especially where we see these poor network conditions, the APR connector spends a lot of its time managing the connection data structure.  That data structure is a ring (doubly linked list with head and tail pointing at each other, which you already know).  That ring is sequentially searched for the socket to remove and it locks all access with a mutex before it does this.  This causes both a CPU consumption issue, as it sequentially walks the linked list, and a blocking problem.  When we first discovered this, I went into the code to see how easy it would be to change it.  I don't think this is a simple fix, and since APR is the underpinning of other things, like Apache HTTPD, not a trivial thing to get accepted by the community either.  This spurred us to look at the NIO2 based connector, which at the time was unsupported, and it didn't exhibit any of this poor behavior.  That's what spurred the effort to move the NIO2 based connector to be fully supported.
> 
> In the absence of poor network conditions, the APR connector behaves and performs well, but in the presence of poor network conditions its not good.  So, with a viable alternative, which Undertow provides out of the box with its XNIO based architecture, there simple seems no good reason to do with for Undertow.
> 
> Thanks.
> 
> -- 
> Andrig (Andy) T. Miller
> Global Platform Director, JBoss Middleware
> Red Hat, Inc.
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/undertow-dev <https://lists.jboss.org/mailman/listinfo/undertow-dev>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150615/7b5845e1/attachment.html 

From jason.greene at redhat.com  Mon Jun 15 14:01:42 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 15 Jun 2015 13:01:42 -0500
Subject: [undertow-dev] Question about APR based connector in Undertow
In-Reply-To: <EF85EEF4-7CD8-44F1-90CF-0CB4E3DEAA28@redhat.com>
References: <24712864.506.1434389385027.JavaMail.andrigtmiller@worklaptop.miller.org>
	<EF85EEF4-7CD8-44F1-90CF-0CB4E3DEAA28@redhat.com>
Message-ID: <B9465A80-5B50-4EB3-9F48-A50F0B486D27@redhat.com>

Oh and I forgot to mention that IMO I think we should prefer contributing optimizations back to the JDK if at all possible, and if not it should be the long term goal.

> On Jun 15, 2015, at 12:51 PM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> We have no intention to do an APR connector. We have had some occasional discussions about whether or not we will need openssl support. Perhaps that?s where it is coming from?
> 
> JFC and Remy had some numbers on JBossWeb that showed poor perf on JSSE vs OpenSSL using APR. It?s somewhat apples vs oranges but looking at the JSSE impl we do see a number of inefficiencies. As an example JSSE seems to do a lot of copying (e.g. anything in a buffer becomes many byte arrays which gets copied again to a buffer). We also see that SHA support on intel is still in a big chunk of java code, and not intrinsic, wheras on openssl its optimized assembler. The new AES GCM ciphers are also known to be slow, but Andrew Haley mentioned that he is in the process of optimizing those. All of this is of course, anecdotal, and until we spend some cycles doing a more apples to apples test I don?t think we can conclude this is a necessary direction.
> 
> The other case where this might matter is how we find a way to support HTTP2. HTTP2 requires that we support the ALPN extension to TLS. Unfortunately JSSE has no support for it, and has been rather slow to implement, and it has to come into 9 before there is any possibility of a backport to 8:
> 
> http://openjdk.java.net/jeps/244 <http://openjdk.java.net/jeps/244>
> https://bugs.openjdk.java.net/browse/JDK-8051498 <https://bugs.openjdk.java.net/browse/JDK-8051498>
> 
> In the meantime we have been reusing a hack that the Jetty guys are maintaining as a separate project, and it requires using bootclasspath to replace core JSSE classes. These hacks are not z-stream compatible, so any JDK bug fix update can break the hack (and this has already happened about 2-3 times).
> 
> So on that perspective we have three options:
> 
> 1)  Red Hat does a Red Hat only hack for IcedTea distributions (not sure if the JDK team would be willing to maintain it or not, would have to ask)
> 2)  Introduce openssl support, which supports ALPN
> 3)  Wait for JSSE, and live with the hack (warning people appropriately)
> 
> At this point, I don?t think we can commit to having anything for the WildFly 10 schedule, unless the performance difference really mandates such a thing, and then we might have to shuffle things around. 
> 
>> On Jun 15, 2015, at 12:29 PM, Andrig T. Miller <anmiller at redhat.com <mailto:anmiller at redhat.com>> wrote:
>> 
>> I am hearing that some work is being put into an APR based connector for Undertow.  I am wondering why we are doing this?
>> 
>> Based on my own testing, and testing the performance team has done with AS 7.x/EAP 6.x/Wildfly, I see no performance reason to do it, and it creates more work for getting product out the door, and maintaining product.
>> 
>> We have found that the APR based connector can exhibit very poor scalability, and consume large amounts of CPU resources when in a network environment that is having problems (TCP resets, dropped and retransmitted packets, etc.).
>> 
>> In this situation, especially where we see these poor network conditions, the APR connector spends a lot of its time managing the connection data structure.  That data structure is a ring (doubly linked list with head and tail pointing at each other, which you already know).  That ring is sequentially searched for the socket to remove and it locks all access with a mutex before it does this.  This causes both a CPU consumption issue, as it sequentially walks the linked list, and a blocking problem.  When we first discovered this, I went into the code to see how easy it would be to change it.  I don't think this is a simple fix, and since APR is the underpinning of other things, like Apache HTTPD, not a trivial thing to get accepted by the community either.  This spurred us to look at the NIO2 based connector, which at the time was unsupported, and it didn't exhibit any of this poor behavior.  That's what spurred the effort to move the NIO2 based connector to be fully supported.
>> 
>> In the absence of poor network conditions, the APR connector behaves and performs well, but in the presence of poor network conditions its not good.  So, with a viable alternative, which Undertow provides out of the box with its XNIO based architecture, there simple seems no good reason to do with for Undertow.
>> 
>> Thanks.
>> 
>> -- 
>> Andrig (Andy) T. Miller
>> Global Platform Director, JBoss Middleware
>> Red Hat, Inc.
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/undertow-dev <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

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150615/4af5c71e/attachment-0001.html 

From i.karpov at cleverdata.ru  Tue Jun 16 07:04:08 2015
From: i.karpov at cleverdata.ru (Ilya Karpov)
Date: Tue, 16 Jun 2015 14:04:08 +0300
Subject: [undertow-dev] Is HttpServerExchange should really be final?
Message-ID: <558002A8.3080103@cleverdata.ru>

Hi, guys,
I'm facing problem of mocking HttpServerExchange via Mockito which fails 
because HttpServerExchange is marked as final. This is a bit 
disappointing and forces me to use other testing framework(e.g. PowerMock).
I've never seen situation where one must use final on class, and many 
situations where it was removed. For example, last time in aerospike 
client code:
BEFORE (watch final method - client can't be mocked)
https://github.com/aerospike/aerospike-client-java/blob/2.1.0/client/src/com/aerospike/client/AerospikeClient.java

AFTER(now final methods are still in place BUT class now implements 
interface I AerospikeClient - client methods now can be mocked via 
mocking interface)
https://github.com/aerospike/aerospike-client-java/blob/3.1.2/client/src/com/aerospike/client/AerospikeClient.java

Can you explain what are the reasons to use final here? May be remove 
final or switch to interface?
-- 
*Ilya Karpov*
Developer

CleverDATA
make your data clever
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150616/91b41729/attachment.html 

From anmiller at redhat.com  Tue Jun 16 10:08:11 2015
From: anmiller at redhat.com (Andrig T. Miller)
Date: Tue, 16 Jun 2015 10:08:11 -0400 (EDT)
Subject: [undertow-dev] Question about APR based connector in Undertow
In-Reply-To: <B9465A80-5B50-4EB3-9F48-A50F0B486D27@redhat.com>
References: <24712864.506.1434389385027.JavaMail.andrigtmiller@worklaptop.miller.org>
	<EF85EEF4-7CD8-44F1-90CF-0CB4E3DEAA28@redhat.com>
	<B9465A80-5B50-4EB3-9F48-A50F0B486D27@redhat.com>
Message-ID: <32560642.1132.1434463689193.JavaMail.andrigtmiller@worklaptop.miller.org>

Okay. I don't have a problem with the openssl part of things, just didn't want to see effort expended on APR, as it was mentioned in a different e-mail thread. 

Thanks Jason. 

Andy 

----- Original Message -----

> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Andrig T. Miller" <anmiller at redhat.com>
> Cc: "undertow-dev" <undertow-dev at lists.jboss.org>
> Sent: Monday, June 15, 2015 12:01:42 PM
> Subject: Re: [undertow-dev] Question about APR based connector in
> Undertow

> Oh and I forgot to mention that IMO I think we should prefer
> contributing optimizations back to the JDK if at all possible, and
> if not it should be the long term goal.

> > On Jun 15, 2015, at 12:51 PM, Jason Greene <
> > jason.greene at redhat.com
> > > wrote:
> 

> > We have no intention to do an APR connector. We have had some
> > occasional discussions about whether or not we will need openssl
> > support. Perhaps that?s where it is coming from?
> 

> > JFC and Remy had some numbers on JBossWeb that showed poor perf on
> > JSSE vs OpenSSL using APR. It?s somewhat apples vs oranges but
> > looking at the JSSE impl we do see a number of inefficiencies. As
> > an
> > example JSSE seems to do a lot of copying (e.g. anything in a
> > buffer
> > becomes many byte arrays which gets copied again to a buffer). We
> > also see that SHA support on intel is still in a big chunk of java
> > code, and not intrinsic, wheras on openssl its optimized assembler.
> > The new AES GCM ciphers are also known to be slow, but Andrew Haley
> > mentioned that he is in the process of optimizing those. All of
> > this
> > is of course, anecdotal, and until we spend some cycles doing a
> > more
> > apples to apples test I don?t think we can conclude this is a
> > necessary direction.
> 

> > The other case where this might matter is how we find a way to
> > support HTTP2. HTTP2 requires that we support the ALPN extension to
> > TLS. Unfortunately JSSE has no support for it, and has been rather
> > slow to implement, and it has to come into 9 before there is any
> > possibility of a backport to 8:
> 

> > http://openjdk.java.net/jeps/244
> 
> > https://bugs.openjdk.java.net/browse/JDK-8051498
> 

> > In the meantime we have been reusing a hack that the Jetty guys are
> > maintaining as a separate project, and it requires using
> > bootclasspath to replace core JSSE classes. These hacks are not
> > z-stream compatible, so any JDK bug fix update can break the hack
> > (and this has already happened about 2-3 times).
> 

> > So on that perspective we have three options:
> 

> > 1) Red Hat does a Red Hat only hack for IcedTea distributions (not
> > sure if the JDK team would be willing to maintain it or not, would
> > have to ask)
> 
> > 2) Introduce openssl support, which supports ALPN
> 
> > 3) Wait for JSSE, and live with the hack (warning people
> > appropriately)
> 

> > At this point, I don?t think we can commit to having anything for
> > the
> > WildFly 10 schedule, unless the performance difference really
> > mandates such a thing, and then we might have to shuffle things
> > around.
> 

> > > On Jun 15, 2015, at 12:29 PM, Andrig T. Miller <
> > > anmiller at redhat.com
> > > > wrote:
> > 
> 

> > > I am hearing that some work is being put into an APR based
> > > connector
> > > for Undertow. I am wondering why we are doing this?
> > 
> 

> > > Based on my own testing, and testing the performance team has
> > > done
> > > with AS 7.x/EAP 6.x/Wildfly, I see no performance reason to do
> > > it,
> > > and it creates more work for getting product out the door, and
> > > maintaining product.
> > 
> 

> > > We have found that the APR based connector can exhibit very poor
> > > scalability, and consume large amounts of CPU resources when in a
> > > network environment that is having problems (TCP resets, dropped
> > > and
> > > retransmitted packets, etc.).
> > 
> 

> > > In this situation, especially where we see these poor network
> > > conditions, the APR connector spends a lot of its time managing
> > > the
> > > connection data structure. That data structure is a ring (doubly
> > > linked list with head and tail pointing at each other, which you
> > > already know). That ring is sequentially searched for the socket
> > > to
> > > remove and it locks all access with a mutex before it does this.
> > > This causes both a CPU consumption issue, as it sequentially
> > > walks
> > > the linked list, and a blocking problem. When we first discovered
> > > this, I went into the code to see how easy it would be to change
> > > it.
> > > I don't think this is a simple fix, and since APR is the
> > > underpinning of other things, like Apache HTTPD, not a trivial
> > > thing
> > > to get accepted by the community either. This spurred us to look
> > > at
> > > the NIO2 based connector, which at the time was unsupported, and
> > > it
> > > didn't exhibit any of this poor behavior. That's what spurred the
> > > effort to move the NIO2 based connector to be fully supported.
> > 
> 

> > > In the absence of poor network conditions, the APR connector
> > > behaves
> > > and performs well, but in the presence of poor network conditions
> > > its not good. So, with a viable alternative, which Undertow
> > > provides
> > > out of the box with its XNIO based architecture, there simple
> > > seems
> > > no good reason to do with for Undertow.
> > 
> 

> > > Thanks.
> > 
> 

> > > --
> > 
> 

> > > Andrig (Andy) T. Miller
> > 
> 
> > > Global Platform Director, JBoss Middleware
> > 
> 
> > > Red Hat, Inc.
> > 
> 
> > > _______________________________________________
> > 
> 
> > > 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
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150616/bd744875/attachment.html 

From epeters at epicor.com  Thu Jun 18 10:57:52 2015
From: epeters at epicor.com (Eric Peters)
Date: Thu, 18 Jun 2015 14:57:52 +0000
Subject: [undertow-dev] Lingering session resources in keepalive
Message-ID: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>

We're still trying to confirm things on our end, so it's still possible a wrong assumption's been made somewhere, but it looks like session resources are lingering with the http connection after the session has expired.

>From one of the heap dumps, following session data that expired the previous day back to a GC root:
http://imgur.com/Ov8xFy1
That's from a dump where the read-timeout was disabled.

We can set the read-timeout, but I don't know if the behavior of keep-alive will limit the impact of the read timeout.  After the reply has been created and sent, do the particulars of the request or reply need to be kept beyond the expiry of the session they were for?

Is there a way to disable keep-alive?  In this particular instance it's more important that the resources be freed up timely than it is that the server use keep-alive to give a boost on performance..

//EricP


This message has been scanned for malware by Websense. www.websense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150618/47c6e177/attachment-0001.html 

From jfclere at gmail.com  Thu Jun 18 12:23:02 2015
From: jfclere at gmail.com (jean-frederic clere)
Date: Thu, 18 Jun 2015 18:23:02 +0200
Subject: [undertow-dev] Question about APR based connector in Undertow
In-Reply-To: <32560642.1132.1434463689193.JavaMail.andrigtmiller@worklaptop.miller.org>
References: <24712864.506.1434389385027.JavaMail.andrigtmiller@worklaptop.miller.org>	<EF85EEF4-7CD8-44F1-90CF-0CB4E3DEAA28@redhat.com>	<B9465A80-5B50-4EB3-9F48-A50F0B486D27@redhat.com>
	<32560642.1132.1434463689193.JavaMail.andrigtmiller@worklaptop.miller.org>
Message-ID: <5582F066.60705@gmail.com>

On 06/16/2015 04:08 PM, Andrig T. Miller wrote:
> Okay.  I don't have a problem with the openssl part of things, just
> didn't want to see effort expended on APR, as it was mentioned in a
> different e-mail thread.

I think we are on the same page APR is useless without OpenSSL, the APR 
connector won't make sense in undertow.

The new thing I have just merged in tc-native allows to use NIO/NIO2 
with OpenSSL, Remy has the code for the NIO/NIO2 connectors of Tomcat 
that should be portable to undertow.

Cheers

Jean-Frederic

>
> Thanks Jason.
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"Jason Greene" <jason.greene at redhat.com>
>     *To: *"Andrig T. Miller" <anmiller at redhat.com>
>     *Cc: *"undertow-dev" <undertow-dev at lists.jboss.org>
>     *Sent: *Monday, June 15, 2015 12:01:42 PM
>     *Subject: *Re: [undertow-dev] Question about APR based connector in
>     Undertow
>
>     Oh and I forgot to mention that IMO I think we should prefer
>     contributing optimizations back to the JDK if at all possible, and
>     if not it should be the long term goal.
>
>         On Jun 15, 2015, at 12:51 PM, Jason Greene
>         <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>
>         We have no intention to do an APR connector. We have had some
>         occasional discussions about whether or not we will need openssl
>         support. Perhaps that?s where it is coming from?
>
>         JFC and Remy had some numbers on JBossWeb that showed poor perf
>         on JSSE vs OpenSSL using APR. It?s somewhat apples vs oranges
>         but looking at the JSSE impl we do see a number of
>         inefficiencies. As an example JSSE seems to do a lot of copying
>         (e.g. anything in a buffer becomes many byte arrays which gets
>         copied again to a buffer). We also see that SHA support on intel
>         is still in a big chunk of java code, and not intrinsic, wheras
>         on openssl its optimized assembler. The new AES GCM ciphers are
>         also known to be slow, but Andrew Haley mentioned that he is in
>         the process of optimizing those. All of this is of course,
>         anecdotal, and until we spend some cycles doing a more apples to
>         apples test I don?t think we can conclude this is a necessary
>         direction.
>
>         The other case where this might matter is how we find a way to
>         support HTTP2. HTTP2 requires that we support the ALPN extension
>         to TLS. Unfortunately JSSE has no support for it, and has been
>         rather slow to implement, and it has to come into 9 before there
>         is any possibility of a backport to 8:
>
>         http://openjdk.java.net/jeps/244
>         https://bugs.openjdk.java.net/browse/JDK-8051498
>
>         In the meantime we have been reusing a hack that the Jetty guys
>         are maintaining as a separate project, and it requires using
>         bootclasspath to replace core JSSE classes. These hacks are not
>         z-stream compatible, so any JDK bug fix update can break the
>         hack (and this has already happened about 2-3 times).
>
>         So on that perspective we have three options:
>
>         1)  Red Hat does a Red Hat only hack for IcedTea distributions
>         (not sure if the JDK team would be willing to maintain it or
>         not, would have to ask)
>         2)  Introduce openssl support, which supports ALPN
>         3)  Wait for JSSE, and live with the hack (warning people
>         appropriately)
>
>         At this point, I don?t think we can commit to having anything
>         for the WildFly 10 schedule, unless the performance difference
>         really mandates such a thing, and then we might have to shuffle
>         things around.
>
>             On Jun 15, 2015, at 12:29 PM, Andrig T. Miller
>             <anmiller at redhat.com <mailto:anmiller at redhat.com>> wrote:
>
>             I am hearing that some work is being put into an APR based
>             connector for Undertow.  I am wondering why we are doing this?
>
>             Based on my own testing, and testing the performance team
>             has done with AS 7.x/EAP 6.x/Wildfly, I see no performance
>             reason to do it, and it creates more work for getting
>             product out the door, and maintaining product.
>
>             We have found that the APR based connector can exhibit very
>             poor scalability, and consume large amounts of CPU resources
>             when in a network environment that is having problems (TCP
>             resets, dropped and retransmitted packets, etc.).
>
>             In this situation, especially where we see these poor
>             network conditions, the APR connector spends a lot of its
>             time managing the connection data structure.  That data
>             structure is a ring (doubly linked list with head and tail
>             pointing at each other, which you already know).  That ring
>             is sequentially searched for the socket to remove and it
>             locks all access with a mutex before it does this.  This
>             causes both a CPU consumption issue, as it sequentially
>             walks the linked list, and a blocking problem.  When we
>             first discovered this, I went into the code to see how easy
>             it would be to change it.  I don't think this is a simple
>             fix, and since APR is the underpinning of other things, like
>             Apache HTTPD, not a trivial thing to get accepted by the
>             community either.  This spurred us to look at the NIO2 based
>             connector, which at the time was unsupported, and it didn't
>             exhibit any of this poor behavior.  That's what spurred the
>             effort to move the NIO2 based connector to be fully supported.
>
>             In the absence of poor network conditions, the APR connector
>             behaves and performs well, but in the presence of poor
>             network conditions its not good.  So, with a viable
>             alternative, which Undertow provides out of the box with its
>             XNIO based architecture, there simple seems no good reason
>             to do with for Undertow.
>
>             Thanks.
>
>             --
>             Andrig (Andy) T. Miller
>             Global Platform Director, JBoss Middleware
>             Red Hat, Inc.
>             _______________________________________________
>             undertow-dev mailing list
>             undertow-dev at lists.jboss.org
>             <mailto: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 <mailto: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
>


From tomaz.cerar at gmail.com  Thu Jun 18 16:46:36 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 18 Jun 2015 22:46:36 +0200
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
Message-ID: <CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>

What version of undertow are you using?

On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters <epeters at epicor.com> wrote:

>  We?re still trying to confirm things on our end, so it?s still possible
> a wrong assumption?s been made somewhere, but it looks like session
> resources are lingering with the http connection after the session has
> expired.
>
>
>
> From one of the heap dumps, following session data that expired the
> previous day back to a GC root:
> http://imgur.com/Ov8xFy1
>
> That?s from a dump where the read-timeout was disabled.
>
>
>
> We can set the read-timeout, but I don?t know if the behavior of
> keep-alive will limit the impact of the read timeout.  After the reply has
> been created and sent, do the particulars of the request or reply need to
> be kept beyond the expiry of the session they were for?
>
>
>
> Is there a way to disable keep-alive?  In this particular instance it?s
> more important that the resources be freed up timely than it is that the
> server use keep-alive to give a boost on performance..
>
>
>
> //EricP
>
>
> This message has been scanned for malware by Websense. www.websense.com
>
> _______________________________________________
> 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/20150618/f1f1c73f/attachment.html 

From epeters at epicor.com  Thu Jun 18 18:10:12 2015
From: epeters at epicor.com (Eric Peters)
Date: Thu, 18 Jun 2015 22:10:12 +0000
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
	<CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
Message-ID: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>

I honestly was expecting the answer to that to be Undertow 1.1.4, but in double-checking I found it?s on Undertow 1.1.0.  Time I skim the patches from 1.1.0 on up to see if anything could have addressed this.

Honestly, I?ve got two angles here:

1)      I need a reliable solution which has a minimum of caveats. Updating in 1.1.x or configuration changes preferred, but if patches are needed, so be it

2)      Did we stumble on a shortcoming in Undertow?  Honestly, I think this can be argued both ways.   If this has merit as a flaw, I?d like to get the find to the right people.

//EricP

From: Toma? Cerar [mailto:tomaz.cerar at gmail.com]
Sent: Thursday, June 18, 2015 2:47 PM
To: Eric Peters
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] Lingering session resources in keepalive

What version of undertow are you using?

On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters <epeters at epicor.com<mailto:epeters at epicor.com>> wrote:
We?re still trying to confirm things on our end, so it?s still possible a wrong assumption?s been made somewhere, but it looks like session resources are lingering with the http connection after the session has expired.

From one of the heap dumps, following session data that expired the previous day back to a GC root:
http://imgur.com/Ov8xFy1
That?s from a dump where the read-timeout was disabled.

We can set the read-timeout, but I don?t know if the behavior of keep-alive will limit the impact of the read timeout.  After the reply has been created and sent, do the particulars of the request or reply need to be kept beyond the expiry of the session they were for?

Is there a way to disable keep-alive?  In this particular instance it?s more important that the resources be freed up timely than it is that the server use keep-alive to give a boost on performance..

//EricP


This message has been scanned for malware by Websense. www.websense.com<http://www.websense.com/>

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev



Click here<https://www.mailcontrol.com/sr/Qqb9boONDZTGX2PQPOmvUjg7ce8j6mWJq8hX!AzyNeEpmvrr+pLvO9ZVWY3fkqP6zvEobm!wVnxjDxGYc2QXWA==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150618/4ddd015e/attachment-0001.html 

From sdouglas at redhat.com  Fri Jun 19 04:00:18 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 19 Jun 2015 04:00:18 -0400 (EDT)
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
	<CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>
Message-ID: <1202663715.25055119.1434700818196.JavaMail.zimbra@redhat.com>

This was fixed in Undertow 1.2: https://github.com/undertow-io/undertow/commit/ca788df7f550513324f11ded155e71f5f3219aa0

Stuart

----- Original Message -----
> From: "Eric Peters" <epeters at epicor.com>
> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 19 June, 2015 12:10:12 AM
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> 
> 
> I honestly was expecting the answer to that to be Undertow 1.1.4, but in
> double-checking I found it?s on Undertow 1.1.0. Time I skim the patches from
> 1.1.0 on up to see if anything could have addressed this.
> 
> 
> 
> Honestly, I?ve got two angles here:
> 
> 1) I need a reliable solution which has a minimum of caveats. Updating in
> 1.1.x or configuration changes preferred, but if patches are needed, so be
> it
> 
> 2) Did we stumble on a shortcoming in Undertow? Honestly, I think this can be
> argued both ways. If this has merit as a flaw, I?d like to get the find to
> the right people.
> 
> 
> 
> //EricP
> 
> 
> 
> From: Toma? Cerar [mailto:tomaz.cerar at gmail.com]
> Sent: Thursday, June 18, 2015 2:47 PM
> To: Eric Peters
> Cc: undertow-dev at lists.jboss.org
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> 
> 
> 
> What version of undertow are you using?
> 
> 
> 
> 
> 
> On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters < epeters at epicor.com > wrote:
> 
> 
> We?re still trying to confirm things on our end, so it?s still possible a
> wrong assumption?s been made somewhere, but it looks like session resources
> are lingering with the http connection after the session has expired.
> 
> 
> 
> From one of the heap dumps, following session data that expired the previous
> day back to a GC root:
> http://imgur.com/Ov8xFy1
> 
> That?s from a dump where the read-timeout was disabled.
> 
> 
> 
> We can set the read-timeout, but I don?t know if the behavior of keep-alive
> will limit the impact of the read timeout. After the reply has been created
> and sent, do the particulars of the request or reply need to be kept beyond
> the expiry of the session they were for?
> 
> 
> 
> Is there a way to disable keep-alive? In this particular instance it?s more
> important that the resources be freed up timely than it is that the server
> use keep-alive to give a boost on performance..
> 
> 
> 
> //EricP
> 
> 
> 
> 
> This message has been scanned for malware by Websense. www.websense.com
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> 
> 
> 
> 
> 
> 
> Click here to report this email as spam.
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Fri Jun 19 04:35:08 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 19 Jun 2015 04:35:08 -0400 (EDT)
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <1202663715.25055119.1434700818196.JavaMail.zimbra@redhat.com>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
	<CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>
	<1202663715.25055119.1434700818196.JavaMail.zimbra@redhat.com>
Message-ID: <1832954799.25082756.1434702908102.JavaMail.zimbra@redhat.com>

I have cut 1.1.5.Final with this fix, although you should look at upgrading to 1.2.8.Final if possible. 

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Eric Peters" <epeters at epicor.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 19 June, 2015 10:00:18 AM
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> This was fixed in Undertow 1.2:
> https://github.com/undertow-io/undertow/commit/ca788df7f550513324f11ded155e71f5f3219aa0
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Eric Peters" <epeters at epicor.com>
> > To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Friday, 19 June, 2015 12:10:12 AM
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > 
> > 
> > I honestly was expecting the answer to that to be Undertow 1.1.4, but in
> > double-checking I found it?s on Undertow 1.1.0. Time I skim the patches
> > from
> > 1.1.0 on up to see if anything could have addressed this.
> > 
> > 
> > 
> > Honestly, I?ve got two angles here:
> > 
> > 1) I need a reliable solution which has a minimum of caveats. Updating in
> > 1.1.x or configuration changes preferred, but if patches are needed, so be
> > it
> > 
> > 2) Did we stumble on a shortcoming in Undertow? Honestly, I think this can
> > be
> > argued both ways. If this has merit as a flaw, I?d like to get the find to
> > the right people.
> > 
> > 
> > 
> > //EricP
> > 
> > 
> > 
> > From: Toma? Cerar [mailto:tomaz.cerar at gmail.com]
> > Sent: Thursday, June 18, 2015 2:47 PM
> > To: Eric Peters
> > Cc: undertow-dev at lists.jboss.org
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > 
> > 
> > 
> > What version of undertow are you using?
> > 
> > 
> > 
> > 
> > 
> > On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters < epeters at epicor.com > wrote:
> > 
> > 
> > We?re still trying to confirm things on our end, so it?s still possible a
> > wrong assumption?s been made somewhere, but it looks like session resources
> > are lingering with the http connection after the session has expired.
> > 
> > 
> > 
> > From one of the heap dumps, following session data that expired the
> > previous
> > day back to a GC root:
> > http://imgur.com/Ov8xFy1
> > 
> > That?s from a dump where the read-timeout was disabled.
> > 
> > 
> > 
> > We can set the read-timeout, but I don?t know if the behavior of keep-alive
> > will limit the impact of the read timeout. After the reply has been created
> > and sent, do the particulars of the request or reply need to be kept beyond
> > the expiry of the session they were for?
> > 
> > 
> > 
> > Is there a way to disable keep-alive? In this particular instance it?s more
> > important that the resources be freed up timely than it is that the server
> > use keep-alive to give a boost on performance..
> > 
> > 
> > 
> > //EricP
> > 
> > 
> > 
> > 
> > This message has been scanned for malware by Websense. www.websense.com
> > 
> > 
> > 
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Click here to report this email as spam.
> > 
> > _______________________________________________
> > 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


From epeters at epicor.com  Fri Jun 19 10:39:17 2015
From: epeters at epicor.com (Eric Peters)
Date: Fri, 19 Jun 2015 14:39:17 +0000
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <1832954799.25082756.1434702908102.JavaMail.zimbra@redhat.com>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
	<CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>
	<1202663715.25055119.1434700818196.JavaMail.zimbra@redhat.com>
	<1832954799.25082756.1434702908102.JavaMail.zimbra@redhat.com>
Message-ID: <EC6BEFB75F25274D811BBA36AD3545F6E8BBD01B@AUS-EX01.epicor.net>

Thanks for pulling the fix in for us.

We're trying to keep churn in our framework to a minimum, which is why we've kept to the same branch that Wildfly 8.2 came with.

We had needed to move to Wildfly 8.2/Undertow, but as a result we've taken a hit from the churn in the libraries.  I'll look into the 1.2 branch, but I wouldn't count on us making the move right away.
//EricP

-----Original Message-----
From: Stuart Douglas [mailto:sdouglas at redhat.com] 
Sent: Friday, June 19, 2015 2:35 AM
To: Eric Peters
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] Lingering session resources in keepalive

I have cut 1.1.5.Final with this fix, although you should look at upgrading to 1.2.8.Final if possible. 

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Eric Peters" <epeters at epicor.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 19 June, 2015 10:00:18 AM
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> This was fixed in Undertow 1.2:
> https://github.com/undertow-io/undertow/commit/ca788df7f550513324f11de
> d155e71f5f3219aa0
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Eric Peters" <epeters at epicor.com>
> > To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Friday, 19 June, 2015 12:10:12 AM
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > 
> > 
> > I honestly was expecting the answer to that to be Undertow 1.1.4, 
> > but in double-checking I found it?s on Undertow 1.1.0. Time I skim 
> > the patches from
> > 1.1.0 on up to see if anything could have addressed this.
> > 
> > 
> > 
> > Honestly, I?ve got two angles here:
> > 
> > 1) I need a reliable solution which has a minimum of caveats. 
> > Updating in 1.1.x or configuration changes preferred, but if patches 
> > are needed, so be it
> > 
> > 2) Did we stumble on a shortcoming in Undertow? Honestly, I think 
> > this can be argued both ways. If this has merit as a flaw, I?d like 
> > to get the find to the right people.
> > 
> > 
> > 
> > //EricP
> > 
> > 
> > 
> > From: Toma? Cerar [mailto:tomaz.cerar at gmail.com]
> > Sent: Thursday, June 18, 2015 2:47 PM
> > To: Eric Peters
> > Cc: undertow-dev at lists.jboss.org
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > 
> > 
> > 
> > What version of undertow are you using?
> > 
> > 
> > 
> > 
> > 
> > On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters < epeters at epicor.com > wrote:
> > 
> > 
> > We?re still trying to confirm things on our end, so it?s still 
> > possible a wrong assumption?s been made somewhere, but it looks like 
> > session resources are lingering with the http connection after the session has expired.
> > 
> > 
> > 
> > From one of the heap dumps, following session data that expired the 
> > previous day back to a GC root:
> > http://imgur.com/Ov8xFy1
> > 
> > That?s from a dump where the read-timeout was disabled.
> > 
> > 
> > 
> > We can set the read-timeout, but I don?t know if the behavior of 
> > keep-alive will limit the impact of the read timeout. After the 
> > reply has been created and sent, do the particulars of the request 
> > or reply need to be kept beyond the expiry of the session they were for?
> > 
> > 
> > 
> > Is there a way to disable keep-alive? In this particular instance 
> > it?s more important that the resources be freed up timely than it is 
> > that the server use keep-alive to give a boost on performance..
> > 
> > 
> > 
> > //EricP
> > 
> > 
> > 
> > 
> > This message has been scanned for malware by Websense. 
> > www.websense.com
> > 
> > 
> > 
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Click here to report this email as spam.
> > 
> > _______________________________________________
> > 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


From joshua.gitlin at gmail.com  Sun Jun 21 16:33:45 2015
From: joshua.gitlin at gmail.com (Joshua Gitlin)
Date: Sun, 21 Jun 2015 16:33:45 -0400
Subject: [undertow-dev] No logging?
Message-ID: <CAOj1phFGUxpG=rRLzWB7Nvi1o9+vO0TMXFT+DxDjV80ov6P2HA@mail.gmail.com>

New to Undertow and just trying to put together a few POCs. I'm having some
issues and I'm not seeing any way to turn any sort of verbose logging.
Looks like none fo the default handlers log anything. Any reason there
aren't debug or trace logs with SLF4J or the like?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150621/9fdb3a84/attachment.html 

From bill at dartalley.com  Sun Jun 21 16:45:59 2015
From: bill at dartalley.com (Bill O'Neil)
Date: Sun, 21 Jun 2015 16:45:59 -0400
Subject: [undertow-dev] No logging?
In-Reply-To: <CAOj1phFGUxpG=rRLzWB7Nvi1o9+vO0TMXFT+DxDjV80ov6P2HA@mail.gmail.com>
References: <CAOj1phFGUxpG=rRLzWB7Nvi1o9+vO0TMXFT+DxDjV80ov6P2HA@mail.gmail.com>
Message-ID: <CANd+gFxms20MGKE5VyPQ90h+R8Cg6bK0v7z90A=8UUiDTF+D6w@mail.gmail.com>

Take a look at AccessLogHandler for logging requests.  You can customize it
quite a bit for more verbose logging.  Just wrap any of your custom
handlers with the AccessLogHandler.

On Sun, Jun 21, 2015 at 4:33 PM, Joshua Gitlin <joshua.gitlin at gmail.com>
wrote:

> New to Undertow and just trying to put together a few POCs. I'm having
> some issues and I'm not seeing any way to turn any sort of verbose logging.
> Looks like none fo the default handlers log anything. Any reason there
> aren't debug or trace logs with SLF4J or the like?
>
> _______________________________________________
> 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/20150621/212d85b6/attachment.html 

From joshua.gitlin at gmail.com  Sun Jun 21 18:31:36 2015
From: joshua.gitlin at gmail.com (Joshua Gitlin)
Date: Sun, 21 Jun 2015 18:31:36 -0400
Subject: [undertow-dev] No logging?
In-Reply-To: <CANd+gFxms20MGKE5VyPQ90h+R8Cg6bK0v7z90A=8UUiDTF+D6w@mail.gmail.com>
References: <CAOj1phFGUxpG=rRLzWB7Nvi1o9+vO0TMXFT+DxDjV80ov6P2HA@mail.gmail.com>
	<CANd+gFxms20MGKE5VyPQ90h+R8Cg6bK0v7z90A=8UUiDTF+D6w@mail.gmail.com>
Message-ID: <CAOj1phFTCLsXCYf9sA6ZP6YaqVLAXfQ5hYvrhmfBS1n2vHkXGQ@mail.gmail.com>

Ah, that works pretty well. Am I nuts are is there nowhere online to find
the javadocs?

On Sun, Jun 21, 2015 at 4:45 PM, Bill O'Neil <bill at dartalley.com> wrote:

> Take a look at AccessLogHandler for logging requests.  You can customize
> it quite a bit for more verbose logging.  Just wrap any of your custom
> handlers with the AccessLogHandler.
>
> On Sun, Jun 21, 2015 at 4:33 PM, Joshua Gitlin <joshua.gitlin at gmail.com>
> wrote:
>
>> New to Undertow and just trying to put together a few POCs. I'm having
>> some issues and I'm not seeing any way to turn any sort of verbose logging.
>> Looks like none fo the default handlers log anything. Any reason there
>> aren't debug or trace logs with SLF4J or the like?
>>
>> _______________________________________________
>> 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/20150621/48841d9c/attachment.html 

From bill at dartalley.com  Sun Jun 21 18:46:34 2015
From: bill at dartalley.com (Bill O'Neil)
Date: Sun, 21 Jun 2015 18:46:34 -0400
Subject: [undertow-dev] No logging?
In-Reply-To: <CAOj1phFTCLsXCYf9sA6ZP6YaqVLAXfQ5hYvrhmfBS1n2vHkXGQ@mail.gmail.com>
References: <CAOj1phFGUxpG=rRLzWB7Nvi1o9+vO0TMXFT+DxDjV80ov6P2HA@mail.gmail.com>
	<CANd+gFxms20MGKE5VyPQ90h+R8Cg6bK0v7z90A=8UUiDTF+D6w@mail.gmail.com>
	<CAOj1phFTCLsXCYf9sA6ZP6YaqVLAXfQ5hYvrhmfBS1n2vHkXGQ@mail.gmail.com>
Message-ID: <CANd+gFyL00khBfkFQtTVvj-QoanaP5eHhpjDCYa+NFC+TZUQ=A@mail.gmail.com>

I'm not sure about the java docs.  I have used
http://undertow.io/undertow-docs/undertow-docs-1.2.0/index.html quite a bit
but it doesn't really outline all the existing handlers anywhere that I
have seen.  Personally I just opened up the io.undertow.server.handlers
package and read through all of the classes.  There are a bunch of very
useful handlers that I only stumbled on from reading through the code.

On Sun, Jun 21, 2015 at 6:31 PM, Joshua Gitlin <joshua.gitlin at gmail.com>
wrote:

> Ah, that works pretty well. Am I nuts are is there nowhere online to find
> the javadocs?
>
> On Sun, Jun 21, 2015 at 4:45 PM, Bill O'Neil <bill at dartalley.com> wrote:
>
>> Take a look at AccessLogHandler for logging requests.  You can customize
>> it quite a bit for more verbose logging.  Just wrap any of your custom
>> handlers with the AccessLogHandler.
>>
>> On Sun, Jun 21, 2015 at 4:33 PM, Joshua Gitlin <joshua.gitlin at gmail.com>
>> wrote:
>>
>>> New to Undertow and just trying to put together a few POCs. I'm having
>>> some issues and I'm not seeing any way to turn any sort of verbose logging.
>>> Looks like none fo the default handlers log anything. Any reason there
>>> aren't debug or trace logs with SLF4J or the like?
>>>
>>> _______________________________________________
>>> 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/20150621/3349e44c/attachment-0001.html 

From greg.hellings at gmail.com  Sun Jun 21 19:16:29 2015
From: greg.hellings at gmail.com (Greg Hellings)
Date: Sun, 21 Jun 2015 18:16:29 -0500
Subject: [undertow-dev] No logging?
In-Reply-To: <CANd+gFyL00khBfkFQtTVvj-QoanaP5eHhpjDCYa+NFC+TZUQ=A@mail.gmail.com>
References: <CAOj1phFGUxpG=rRLzWB7Nvi1o9+vO0TMXFT+DxDjV80ov6P2HA@mail.gmail.com>
	<CANd+gFxms20MGKE5VyPQ90h+R8Cg6bK0v7z90A=8UUiDTF+D6w@mail.gmail.com>
	<CAOj1phFTCLsXCYf9sA6ZP6YaqVLAXfQ5hYvrhmfBS1n2vHkXGQ@mail.gmail.com>
	<CANd+gFyL00khBfkFQtTVvj-QoanaP5eHhpjDCYa+NFC+TZUQ=A@mail.gmail.com>
Message-ID: <CAHxvOVJFST-2XznBicA84UDAtmBRUQ8StykR--iPK4J8ZUOktg@mail.gmail.com>

Until very recently the javadocs weren't generating due to syntax
errors. My PR to master to fix those was accepted several weeks back.
You should be able to generate them yourself off master now, but I
haven't tried it since. Adding "mvn javadoc:javadoc" to any automated
tests might be a good idea to help make sure more errors don't creep
in.

--Greg

On Sun, Jun 21, 2015 at 5:46 PM, Bill O'Neil <bill at dartalley.com> wrote:
> I'm not sure about the java docs.  I have used
> http://undertow.io/undertow-docs/undertow-docs-1.2.0/index.html quite a bit
> but it doesn't really outline all the existing handlers anywhere that I have
> seen.  Personally I just opened up the io.undertow.server.handlers package
> and read through all of the classes.  There are a bunch of very useful
> handlers that I only stumbled on from reading through the code.
>
> On Sun, Jun 21, 2015 at 6:31 PM, Joshua Gitlin <joshua.gitlin at gmail.com>
> wrote:
>>
>> Ah, that works pretty well. Am I nuts are is there nowhere online to find
>> the javadocs?
>>
>> On Sun, Jun 21, 2015 at 4:45 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>>
>>> Take a look at AccessLogHandler for logging requests.  You can customize
>>> it quite a bit for more verbose logging.  Just wrap any of your custom
>>> handlers with the AccessLogHandler.
>>>
>>> On Sun, Jun 21, 2015 at 4:33 PM, Joshua Gitlin <joshua.gitlin at gmail.com>
>>> wrote:
>>>>
>>>> New to Undertow and just trying to put together a few POCs. I'm having
>>>> some issues and I'm not seeing any way to turn any sort of verbose logging.
>>>> Looks like none fo the default handlers log anything. Any reason there
>>>> aren't debug or trace logs with SLF4J or the like?
>>>>
>>>> _______________________________________________
>>>> 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

From epeters at epicor.com  Mon Jun 22 13:46:28 2015
From: epeters at epicor.com (Eric Peters)
Date: Mon, 22 Jun 2015 17:46:28 +0000
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <EC6BEFB75F25274D811BBA36AD3545F6E8BBD01B@AUS-EX01.epicor.net>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
	<CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>
	<1202663715.25055119.1434700818196.JavaMail.zimbra@redhat.com>
	<1832954799.25082756.1434702908102.JavaMail.zimbra@redhat.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBD01B@AUS-EX01.epicor.net>
Message-ID: <EC6BEFB75F25274D811BBA36AD3545F6E8BBD430@AUS-EX01.epicor.net>

I'm trying to find references or doc for upgrading Undertow to 1.2.x in Wildfly 8.2, but I'm not finding much - is this practical/safe?  Or would it be better to upgrade Wildfly?

//EricP

-----Original Message-----
From: undertow-dev-bounces at lists.jboss.org [mailto:undertow-dev-bounces at lists.jboss.org] On Behalf Of Eric Peters
Sent: Friday, June 19, 2015 8:39 AM
To: Stuart Douglas
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] Lingering session resources in keepalive

Thanks for pulling the fix in for us.

We're trying to keep churn in our framework to a minimum, which is why we've kept to the same branch that Wildfly 8.2 came with.

We had needed to move to Wildfly 8.2/Undertow, but as a result we've taken a hit from the churn in the libraries.  I'll look into the 1.2 branch, but I wouldn't count on us making the move right away.
//EricP

-----Original Message-----
From: Stuart Douglas [mailto:sdouglas at redhat.com]
Sent: Friday, June 19, 2015 2:35 AM
To: Eric Peters
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] Lingering session resources in keepalive

I have cut 1.1.5.Final with this fix, although you should look at upgrading to 1.2.8.Final if possible. 

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Eric Peters" <epeters at epicor.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 19 June, 2015 10:00:18 AM
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> This was fixed in Undertow 1.2:
> https://github.com/undertow-io/undertow/commit/ca788df7f550513324f11de
> d155e71f5f3219aa0
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Eric Peters" <epeters at epicor.com>
> > To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Friday, 19 June, 2015 12:10:12 AM
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > 
> > 
> > I honestly was expecting the answer to that to be Undertow 1.1.4, 
> > but in double-checking I found it?s on Undertow 1.1.0. Time I skim 
> > the patches from
> > 1.1.0 on up to see if anything could have addressed this.
> > 
> > 
> > 
> > Honestly, I?ve got two angles here:
> > 
> > 1) I need a reliable solution which has a minimum of caveats. 
> > Updating in 1.1.x or configuration changes preferred, but if patches 
> > are needed, so be it
> > 
> > 2) Did we stumble on a shortcoming in Undertow? Honestly, I think 
> > this can be argued both ways. If this has merit as a flaw, I?d like 
> > to get the find to the right people.
> > 
> > 
> > 
> > //EricP
> > 
> > 
> > 
> > From: Toma? Cerar [mailto:tomaz.cerar at gmail.com]
> > Sent: Thursday, June 18, 2015 2:47 PM
> > To: Eric Peters
> > Cc: undertow-dev at lists.jboss.org
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > 
> > 
> > 
> > What version of undertow are you using?
> > 
> > 
> > 
> > 
> > 
> > On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters < epeters at epicor.com > wrote:
> > 
> > 
> > We?re still trying to confirm things on our end, so it?s still 
> > possible a wrong assumption?s been made somewhere, but it looks like 
> > session resources are lingering with the http connection after the session has expired.
> > 
> > 
> > 
> > From one of the heap dumps, following session data that expired the 
> > previous day back to a GC root:
> > http://imgur.com/Ov8xFy1
> > 
> > That?s from a dump where the read-timeout was disabled.
> > 
> > 
> > 
> > We can set the read-timeout, but I don?t know if the behavior of 
> > keep-alive will limit the impact of the read timeout. After the 
> > reply has been created and sent, do the particulars of the request 
> > or reply need to be kept beyond the expiry of the session they were for?
> > 
> > 
> > 
> > Is there a way to disable keep-alive? In this particular instance 
> > it?s more important that the resources be freed up timely than it is 
> > that the server use keep-alive to give a boost on performance..
> > 
> > 
> > 
> > //EricP
> > 
> > 
> > 
> > 
> > This message has been scanned for malware by Websense. 
> > www.websense.com
> > 
> > 
> > 
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Click here to report this email as spam.
> > 
> > _______________________________________________
> > 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


From sdouglas at redhat.com  Mon Jun 22 15:09:50 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 22 Jun 2015 15:09:50 -0400 (EDT)
Subject: [undertow-dev] Lingering session resources in keepalive
In-Reply-To: <EC6BEFB75F25274D811BBA36AD3545F6E8BBD430@AUS-EX01.epicor.net>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBCBB9@AUS-EX01.epicor.net>
	<CAMquZP6+i6zc9LJ2zQVQthYgOLwjTDLj-nPknuBB22cejvOf_g@mail.gmail.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBCF80@AUS-EX01.epicor.net>
	<1202663715.25055119.1434700818196.JavaMail.zimbra@redhat.com>
	<1832954799.25082756.1434702908102.JavaMail.zimbra@redhat.com>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBD01B@AUS-EX01.epicor.net>
	<EC6BEFB75F25274D811BBA36AD3545F6E8BBD430@AUS-EX01.epicor.net>
Message-ID: <282125365.26802821.1435000190752.JavaMail.zimbra@redhat.com>

Better to upgrade Wildfly, but it "should" be possible to just drop the newer version of Undertow in.

Stuart

----- Original Message -----
> From: "Eric Peters" <epeters at epicor.com>
> To: "Eric Peters" <epeters at epicor.com>, "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 22 June, 2015 7:46:28 PM
> Subject: RE: [undertow-dev] Lingering session resources in keepalive
> 
> I'm trying to find references or doc for upgrading Undertow to 1.2.x in
> Wildfly 8.2, but I'm not finding much - is this practical/safe?  Or would it
> be better to upgrade Wildfly?
> 
> //EricP
> 
> -----Original Message-----
> From: undertow-dev-bounces at lists.jboss.org
> [mailto:undertow-dev-bounces at lists.jboss.org] On Behalf Of Eric Peters
> Sent: Friday, June 19, 2015 8:39 AM
> To: Stuart Douglas
> Cc: undertow-dev at lists.jboss.org
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> Thanks for pulling the fix in for us.
> 
> We're trying to keep churn in our framework to a minimum, which is why we've
> kept to the same branch that Wildfly 8.2 came with.
> 
> We had needed to move to Wildfly 8.2/Undertow, but as a result we've taken a
> hit from the churn in the libraries.  I'll look into the 1.2 branch, but I
> wouldn't count on us making the move right away.
> //EricP
> 
> -----Original Message-----
> From: Stuart Douglas [mailto:sdouglas at redhat.com]
> Sent: Friday, June 19, 2015 2:35 AM
> To: Eric Peters
> Cc: undertow-dev at lists.jboss.org
> Subject: Re: [undertow-dev] Lingering session resources in keepalive
> 
> I have cut 1.1.5.Final with this fix, although you should look at upgrading
> to 1.2.8.Final if possible.
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "Eric Peters" <epeters at epicor.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Friday, 19 June, 2015 10:00:18 AM
> > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > 
> > This was fixed in Undertow 1.2:
> > https://github.com/undertow-io/undertow/commit/ca788df7f550513324f11de
> > d155e71f5f3219aa0
> > 
> > Stuart
> > 
> > ----- Original Message -----
> > > From: "Eric Peters" <epeters at epicor.com>
> > > To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Friday, 19 June, 2015 12:10:12 AM
> > > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > > 
> > > 
> > > 
> > > I honestly was expecting the answer to that to be Undertow 1.1.4,
> > > but in double-checking I found it?s on Undertow 1.1.0. Time I skim
> > > the patches from
> > > 1.1.0 on up to see if anything could have addressed this.
> > > 
> > > 
> > > 
> > > Honestly, I?ve got two angles here:
> > > 
> > > 1) I need a reliable solution which has a minimum of caveats.
> > > Updating in 1.1.x or configuration changes preferred, but if patches
> > > are needed, so be it
> > > 
> > > 2) Did we stumble on a shortcoming in Undertow? Honestly, I think
> > > this can be argued both ways. If this has merit as a flaw, I?d like
> > > to get the find to the right people.
> > > 
> > > 
> > > 
> > > //EricP
> > > 
> > > 
> > > 
> > > From: Toma? Cerar [mailto:tomaz.cerar at gmail.com]
> > > Sent: Thursday, June 18, 2015 2:47 PM
> > > To: Eric Peters
> > > Cc: undertow-dev at lists.jboss.org
> > > Subject: Re: [undertow-dev] Lingering session resources in keepalive
> > > 
> > > 
> > > 
> > > 
> > > What version of undertow are you using?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Thu, Jun 18, 2015 at 4:57 PM, Eric Peters < epeters at epicor.com >
> > > wrote:
> > > 
> > > 
> > > We?re still trying to confirm things on our end, so it?s still
> > > possible a wrong assumption?s been made somewhere, but it looks like
> > > session resources are lingering with the http connection after the
> > > session has expired.
> > > 
> > > 
> > > 
> > > From one of the heap dumps, following session data that expired the
> > > previous day back to a GC root:
> > > http://imgur.com/Ov8xFy1
> > > 
> > > That?s from a dump where the read-timeout was disabled.
> > > 
> > > 
> > > 
> > > We can set the read-timeout, but I don?t know if the behavior of
> > > keep-alive will limit the impact of the read timeout. After the
> > > reply has been created and sent, do the particulars of the request
> > > or reply need to be kept beyond the expiry of the session they were for?
> > > 
> > > 
> > > 
> > > Is there a way to disable keep-alive? In this particular instance
> > > it?s more important that the resources be freed up timely than it is
> > > that the server use keep-alive to give a boost on performance..
> > > 
> > > 
> > > 
> > > //EricP
> > > 
> > > 
> > > 
> > > 
> > > This message has been scanned for malware by Websense.
> > > www.websense.com
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Click here to report this email as spam.
> > > 
> > > _______________________________________________
> > > 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
> 


From epeters at epicor.com  Thu Jun 25 18:39:00 2015
From: epeters at epicor.com (Eric Peters)
Date: Thu, 25 Jun 2015 22:39:00 +0000
Subject: [undertow-dev] InSessionMemoryManager synchronized methods
Message-ID: <EC6BEFB75F25274D811BBA36AD3545F6E8BBDD39@AUS-EX01.epicor.net>

Chasing after another problem I found several blocked task threads, best as I can determine:
InMemorySessionmanager$SessionImpl.invalidate() is invoked.
This method is synchronized, and the call blocks inside SesssionListeners.sessionDestroyed() (separate issue there...)

Later, InMemorySessionmanager$SessionImpl.bumpTimeout() is invoked from another thread.
This method is also synchronized, and blocks waiting for invalidate() to complete.  As the first thread is indefinitely blocked inside invalidate(), this second thread also remains blocked indefinitely.

In my environment it appears to make an existing problem slightly more severe.

Found in 1.1.0, but it looks like it's in both 1.1.7 and the master branch as well.
Using RHEL, Java 7, Wildfly 8.2

invalidate() Thread trace (excerpt):

  *   (blocked) - sun.misc.Unsafe.park(boolean, long)
  *   ...
  *   org.jboss.seam.contexts.ServletLifecycle.endSession(javax.servlet.http.HttpSession) (line: 187)
  *   org.jboss.seam.servlet.SeamListener.sessionDestroyed(javax.servlet.http.HttpSessionEvent) (line: 59)
  *   io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(javax.servlet.http.HttpSession) (line: 264)
  *   io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 67)
  *   io.undertow.server.session.SessionListeners.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 61)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 413)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange) (line: 399)
  *   io.undertow.servlet.spec.HttpSessionImpl.invalidate() (line: 197)
  *   ...

bumpTimeout() Thread trace:

  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() (line: 271)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) (line: 355)
  *   io.undertow.servlet.util.SavedRequest.tryRestoreRequest(io.undertow.server.HttpServerExchange, javax.servlet.http.HttpSession) (line: 124)
  *   io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 67)
  *   io.undertow.security.handlers.SecurityInitialHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 76)
  *   io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
  *   org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 61)
  *   io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
  *   io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
  *   io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletChain, io.undertow.servlet.handlers.ServletRequestContext, javax.servlet.ServletRequest, javax.servlet.ServletResponse) (line: 261)
  *   io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) (line: 247)
  *   io.undertow.servlet.handlers.ServletInitialHandler.access$000(io.undertow.servlet.handlers.ServletInitialHandler, io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType)
  *   io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(io.undertow.server.HttpServerExchange) (line: 166)
  *   io.undertow.server.Connectors.executeRootHandler(io.undertow.server.HttpHandler, io.undertow.server.HttpServerExchange) (line: 197)
  *   io.undertow.server.HttpServerExchange$1.run() (line: 759)
  *   java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1145)
  *   java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 615)
  *   java.lang.Thread.run() (line: 745)
//EricP



This message has been scanned for malware by Websense. www.websense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150625/e3c9b03e/attachment-0001.html 

From epeters at epicor.com  Thu Jun 25 19:22:42 2015
From: epeters at epicor.com (Eric Peters)
Date: Thu, 25 Jun 2015 23:22:42 +0000
Subject: [undertow-dev] InSessionMemoryManager synchronized methods
In-Reply-To: <EC6BEFB75F25274D811BBA36AD3545F6E8BBDD39@AUS-EX01.epicor.net>
References: <EC6BEFB75F25274D811BBA36AD3545F6E8BBDD39@AUS-EX01.epicor.net>
Message-ID: <EC6BEFB75F25274D811BBA36AD3545F6E8BBDD6D@AUS-EX01.epicor.net>

I stand corrected - This is 50% of what brought our server down.

The other half of the deadlock belongs to Seam:


  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() (line: 271)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) (line: 355)
  *   io.undertow.servlet.spec.HttpSessionImpl.getAttribute(java.lang.String)
  *   com.sun.faces.context.SessionMap.get(java.lang.Object)
  *   org.jboss.seam.contexts.ServerConversationContext.get(java.lang.String) (line: 110)
  *   org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(java.lang.String) (line: 189)
  *   org.jboss.seam.Component.getInstanceFromFactory(java.lang.String, org.jboss.seam.ScopeType) (line: 2088)
  *   org.jboss.seam.Component.getInstance(java.lang.String, boolean, boolean, java.lang.Object, org.jboss.seam.ScopeType) (line: 2014)
  *   org.jboss.seam.Component.getInstance(java.lang.String, boolean, boolean) (line: 1986)
  *   org.jboss.seam.Component.getInstance(java.lang.String, boolean)
  *   org.jboss.seam.Namespace.getComponentInstance(java.lang.String, boolean)

org.jboss.seam.Component.getInstanceFromFactory() obtains a lock that has static scope, so nothing else can invoke getInstanceFromFacotry() while the lock is held.It then blocks on InMemorySessionManager$SessionImpl.bumpTimeout()
Meanwhile, the invalidate() method blocks against the static method in getInstanceFromFactory()
//EricP




From: undertow-dev-bounces at lists.jboss.org [mailto:undertow-dev-bounces at lists.jboss.org] On Behalf Of Eric Peters
Sent: Thursday, June 25, 2015 4:39 PM
To: undertow-dev at lists.jboss.org
Subject: [undertow-dev] InSessionMemoryManager synchronized methods

Chasing after another problem I found several blocked task threads, best as I can determine:
InMemorySessionmanager$SessionImpl.invalidate() is invoked.
This method is synchronized, and the call blocks inside SesssionListeners.sessionDestroyed() (separate issue there...)

Later, InMemorySessionmanager$SessionImpl.bumpTimeout() is invoked from another thread.
This method is also synchronized, and blocks waiting for invalidate() to complete.  As the first thread is indefinitely blocked inside invalidate(), this second thread also remains blocked indefinitely.

In my environment it appears to make an existing problem slightly more severe.

Found in 1.1.0, but it looks like it's in both 1.1.7 and the master branch as well.
Using RHEL, Java 7, Wildfly 8.2

invalidate() Thread trace (excerpt):

  *   (blocked) - sun.misc.Unsafe.park(boolean, long)
  *   ...
  *   org.jboss.seam.contexts.ServletLifecycle.endSession(javax.servlet.http.HttpSession) (line: 187)
  *   org.jboss.seam.servlet.SeamListener.sessionDestroyed(javax.servlet.http.HttpSessionEvent) (line: 59)
  *   io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(javax.servlet.http.HttpSession) (line: 264)
  *   io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 67)
  *   io.undertow.server.session.SessionListeners.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 61)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 413)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange) (line: 399)
  *   io.undertow.servlet.spec.HttpSessionImpl.invalidate() (line: 197)
  *   ...

bumpTimeout() Thread trace:

  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() (line: 271)
  *   io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) (line: 355)
  *   io.undertow.servlet.util.SavedRequest.tryRestoreRequest(io.undertow.server.HttpServerExchange, javax.servlet.http.HttpSession) (line: 124)
  *   io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 67)
  *   io.undertow.security.handlers.SecurityInitialHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 76)
  *   io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
  *   org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 61)
  *   io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
  *   io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
  *   io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletChain, io.undertow.servlet.handlers.ServletRequestContext, javax.servlet.ServletRequest, javax.servlet.ServletResponse) (line: 261)
  *   io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) (line: 247)
  *   io.undertow.servlet.handlers.ServletInitialHandler.access$000(io.undertow.servlet.handlers.ServletInitialHandler, io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType)
  *   io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(io.undertow.server.HttpServerExchange) (line: 166)
  *   io.undertow.server.Connectors.executeRootHandler(io.undertow.server.HttpHandler, io.undertow.server.HttpServerExchange) (line: 197)
  *   io.undertow.server.HttpServerExchange$1.run() (line: 759)
  *   java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1145)
  *   java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 615)
  *   java.lang.Thread.run() (line: 745)
//EricP



This message has been scanned for malware by Websense. www.websense.com<http://www.websense.com/>


Click here<https://www.mailcontrol.com/sr/qFsLDesiAOTGX2PQPOmvUk8LIR8eqmo3fP!Z+Zd24fwdO9XGlCVXypUHpd+quuDmLK9zr65hnE4eRLY+cWrx9g==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150625/988c8e5a/attachment-0001.html