From toby at tcrawley.org  Fri Mar  4 15:29:00 2016
From: toby at tcrawley.org (Toby Crawley)
Date: Fri, 4 Mar 2016 15:29:00 -0500
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
	1.3.18.Final
Message-ID: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>

Is there a known decrease in throughput (measured with req/s)
between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
with Immutant, and were looking at upgrading to the latter in the next
release, but noticed a decrease in throughput with a simple Clojure
benchmark app.

I have replicated the basics of our benchmark app in Java[1], and saw a
decrease in req/s between the two versions of ~7% when testing with ab
and averaging the output of several runs.

Is there something that changed between those versions that is known
to have reduced performance?

- Toby

[1]: https://github.com/tobias/undertow-speed

From sdouglas at redhat.com  Sun Mar  6 18:59:27 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 6 Mar 2016 18:59:27 -0500 (EST)
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9
	and	1.3.18.Final
In-Reply-To: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
Message-ID: <1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>

This is not a known issue, I will investigate.

Stuart

----- Original Message -----
> From: "Toby Crawley" <toby at tcrawley.org>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 5 March, 2016 7:29:00 AM
> Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and	1.3.18.Final
> 
> Is there a known decrease in throughput (measured with req/s)
> between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
> with Immutant, and were looking at upgrading to the latter in the next
> release, but noticed a decrease in throughput with a simple Clojure
> benchmark app.
> 
> I have replicated the basics of our benchmark app in Java[1], and saw a
> decrease in req/s between the two versions of ~7% when testing with ab
> and averaging the output of several runs.
> 
> Is there something that changed between those versions that is known
> to have reduced performance?
> 
> - Toby
> 
> [1]: https://github.com/tobias/undertow-speed
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From STEPHEN.A.GORMAN at leidos.com  Tue Mar  1 13:54:25 2016
From: STEPHEN.A.GORMAN at leidos.com (Gorman, Steve A.)
Date: Tue, 1 Mar 2016 18:54:25 +0000
Subject: [undertow-dev] WSS Java Client Examplt
Message-ID: <A51AB3A356CE1C4B9455DC1F87039037B519A975@EMP-EXMR104.corp.leidos.com>

All,
I have a J2EE project that runs a Resource Adapter to allow some socket communications to a CPP app, all running in Wildfly 9. I now want to write a java socket listener that reads broadcast messages on a TCP/IP connection and forward those broadcast message to a bunch of browser sessions. My deployment structure is ..

artifact.ear
      JcaAdapter.rar  (tcp/ip socket reader lives in here)
      BusinessLogic.war (   jcaAdapter.getConnection() and receive tcp/ip messages )


Inside my BusinessLogic.war I have created a javax @ServerEndpoint("/broadcasts/") websocket endpoint for the JS browser clients. Inside my JcaAdapter.rar I have put a TCP/IP socket reader which constantly listens for broadcast messages. When they arrive I want to have a Java based WSS websocket client that sends the messages to the @ServerEndpoint websocket. My Wildfly instance is SSL so my web socket java client has to be WSS.

I have scoured the internet and safari books looking for an example client for WSS written in Java but have found nothing.

Any help or advice is so very appreciated.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160301/69b09b93/attachment-0001.html 

From Benno.Geisselmann at bosch-si.com  Thu Mar  3 10:09:14 2016
From: Benno.Geisselmann at bosch-si.com (Geisselmann Benno (INST/ECS1))
Date: Thu, 3 Mar 2016 15:09:14 +0000
Subject: [undertow-dev] Change response body in Undertow
Message-ID: <BDF7ED6B3F93E44497FEFC22F101DA014BCF808F@imbpw2exd01.bosch-si.com>

Hi,


Can you tell me, whether it is possible to change the Body of a request response (within HttpServerExchange) if this response has already been created by another handler? I saw that I can change for example the response status code, but it seems like I cannot change the response body.



Thanks for your help.

Benno Gei?elmann

Bosch Software Innovations GmbH

www.blog.bosch-si.com<http://www.blog.bosch-si.com/>
www.bosch-si.de

benno.geisselmann at bosch-si.com<mailto:benno.geisselmann at bosch-si.com>

Registered office: Berlin, Register court: Amtsgericht Charlottenburg; HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160303/5018f6d7/attachment-0001.html 

From shivasaxena999 at gmail.com  Sat Mar  5 05:51:06 2016
From: shivasaxena999 at gmail.com (Shiva Saxena)
Date: Sat, 5 Mar 2016 16:21:06 +0530
Subject: [undertow-dev] java.lang.NoClassDefFoundError:
	freemarker/cache/TemplateLoader
Message-ID: <CADjggukz48Pqhs5Wv3no=_n=qwXsYzo9dQMbx0p3g7S4ey0USQ@mail.gmail.com>

Hi,

I am just creating a Hello world example of undertow.js like so

$undertow
.onGet("/hello-freemarker",
   {template: '/resources/hello.ftl','template_type': 'freemarker',
headers: {"content-type": "text/plain"}},
   [function ($exchange) {
       return {data: 'Hello World!'};
   }]);

When deploying the project I am getting the following exception

ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2)
MSC000001: Failed to start service
jboss.undertow.deployment.default-server.default-host./undertowjs-example:
org.jboss.msc.service.StartException in service
jboss.undertow.deployment.default-server.default-host./undertowjs-example:
java.util.ServiceConfigurationError:
io.undertow.js.templates.TemplateProvider: Provider
io.undertow.js.templates.freemarker.FreemarkerTemplateProvider could not be
instantiated
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)

I have also added the freemarker jar file in the modules folder but it
still doesn't  help. Please let me know what I might be doing wrong or is
come extra conf required.

-- 
Best Regards
*Shiva Saxena*
*Mobile : +91-9889787094                            *
*Blog <http://metalop.com/> | Linkedin
<http://in.linkedin.com/in/shivasaxena/> | StackOverflow
<http://stackoverflow.com/users/2490343/shiva>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160305/67c8d52a/attachment-0001.html 

From sdouglas at redhat.com  Mon Mar  7 17:14:27 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 7 Mar 2016 17:14:27 -0500 (EST)
Subject: [undertow-dev]
	java.lang.NoClassDefFoundError:	freemarker/cache/TemplateLoader
In-Reply-To: <CADjggukz48Pqhs5Wv3no=_n=qwXsYzo9dQMbx0p3g7S4ey0USQ@mail.gmail.com>
References: <CADjggukz48Pqhs5Wv3no=_n=qwXsYzo9dQMbx0p3g7S4ey0USQ@mail.gmail.com>
Message-ID: <126196445.34426313.1457388867210.JavaMail.zimbra@redhat.com>

Wildfly only bundles the mustache template library by default, if you want to use Freemarker you need to bundle it in your deployment.

Stuart

----- Original Message -----
> From: "Shiva Saxena" <shivasaxena999 at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 5 March, 2016 9:51:06 PM
> Subject: [undertow-dev] java.lang.NoClassDefFoundError:	freemarker/cache/TemplateLoader
> 
> Hi,
> 
> I am just creating a Hello world example of undertow.js like so
> 
> $undertow
> .onGet("/hello-freemarker",
> {template: '/resources/hello.ftl','template_type': 'freemarker', headers:
> {"content-type": "text/plain"}},
> [function ($exchange) {
> return {data: 'Hello World!'};
> }]);
> When deploying the project I am getting the following exception
> 
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2)
> MSC000001: Failed to start service
> jboss.undertow.deployment.default-server.default-host./undertowjs-example:
> org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./undertowjs-example:
> java.util.ServiceConfigurationError:
> io.undertow.js.templates.TemplateProvider: Provider
> io.undertow.js.templates.freemarker.FreemarkerTemplateProvider could not be
> instantiated
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> 
> I have also added the freemarker jar file in the modules folder but it still
> doesn't help. Please let me know what I might be doing wrong or is come
> extra conf required.
> 
> --
> Best Regards
> Shiva Saxena
> Mobile : +91-9889787094
> Blog | Linkedin | StackOverflow
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Mon Mar  7 17:27:07 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 7 Mar 2016 17:27:07 -0500 (EST)
Subject: [undertow-dev] WSS Java Client Examplt
In-Reply-To: <A51AB3A356CE1C4B9455DC1F87039037B519A975@EMP-EXMR104.corp.leidos.com>
References: <A51AB3A356CE1C4B9455DC1F87039037B519A975@EMP-EXMR104.corp.leidos.com>
Message-ID: <1228234146.34429144.1457389627971.JavaMail.zimbra@redhat.com>

There is an example in the Undertow test suite here:

https://github.com/undertow-io/undertow/blob/master/websockets-jsr/src/test/java/io/undertow/websockets/jsr/test/ProgramaticLazyEndpointTest.java#L97

Basically there is no standard way to do this with the web socket API, instead you need to pass in a SSLContext under the io.undertow.websocket.SSL_CONTEXT property name. 

We also provide other ways to do this, you can implement io.undertow.websockets.jsr.WebsocketClientSslProvider (and add a META-INF/services entry for your implementation) or call io.undertow.websockets.jsr.DefaultWebSocketClientSslProvider#setSslContext() to set a thread local SSL context.

Stuart


----- Original Message -----
> From: "Steve A. Gorman" <STEPHEN.A.GORMAN at leidos.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 2 March, 2016 5:54:25 AM
> Subject: [undertow-dev] WSS Java Client Examplt
> 
> 
> 
> All,
> 
> I have a J2EE project that runs a Resource Adapter to allow some socket
> communications to a CPP app, all running in Wildfly 9. I now want to write a
> java socket listener that reads broadcast messages on a TCP/IP connection
> and forward those broadcast message to a bunch of browser sessions. My
> deployment structure is ..
> 
> 
> 
> artifact.ear
> 
> JcaAdapter.rar (tcp/ip socket reader lives in here)
> 
> BusinessLogic.war ( jcaAdapter.getConnection() and receive tcp/ip messages )
> 
> 
> 
> 
> 
> Inside my BusinessLogic.war I have created a javax
> @ServerEndpoint(?/broadcasts/?) websocket endpoint for the JS browser
> clients. Inside my JcaAdapter.rar I have put a TCP/IP socket reader which
> constantly listens for broadcast messages. When they arrive I want to have a
> Java based WSS websocket client that sends the messages to the
> @ServerEndpoint websocket. My Wildfly instance is SSL so my web socket java
> client has to be WSS.
> 
> 
> 
> I have scoured the internet and safari books looking for an example client
> for WSS written in Java but have found nothing.
> 
> 
> 
> Any help or advice is so very appreciated.
> 
> 
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Mon Mar  7 17:52:59 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 7 Mar 2016 17:52:59 -0500 (EST)
Subject: [undertow-dev] Change response body in Undertow
In-Reply-To: <BDF7ED6B3F93E44497FEFC22F101DA014BCF808F@imbpw2exd01.bosch-si.com>
References: <BDF7ED6B3F93E44497FEFC22F101DA014BCF808F@imbpw2exd01.bosch-si.com>
Message-ID: <243243838.34436394.1457391179723.JavaMail.zimbra@redhat.com>

You need to implement org.xnio.conduits.StreamSinkConduit and add io.undertow.server.HttpServerExchange#addResponseWrapper

There is no simple in memory representation of the response, because it may be to large for the server to buffer (or more likely the server does not want to buffer it for performance reasons). Implementing this will allow you to modify the response as it is being written.


Stuart

----- Original Message -----
> From: "Geisselmann Benno (INST/ECS1)" <Benno.Geisselmann at bosch-si.com>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 4 March, 2016 2:09:14 AM
> Subject: [undertow-dev] Change response body in Undertow
> 
> 
> 
> Hi,
> 
> 
> Can you tell me, whether it is possible to change the Body of a request
> response (within HttpServerExchange) if this response has already been
> created by another handler? I saw that I can change for example the response
> status code, but it seems like I cannot change the response body.
> Thanks for your help.
> 
> 
> 
> 
> Benno Gei?elmann
> 
> 
> 
> Bosch Software Innovations GmbH
> 
> 
> 
> www.blog.bosch-si.com
> 
> www.bosch-si.de
> 
> 
> 
> benno.geisselmann at bosch-si.com
> 
> 
> 
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg; HRB
> 148411 B ;
> 
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> 
> 
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From blue at nqzero.com  Tue Mar  8 11:52:04 2016
From: blue at nqzero.com (seth/nqzero)
Date: Tue, 8 Mar 2016 11:52:04 -0500
Subject: [undertow-dev] Change response body in Undertow
In-Reply-To: <BDF7ED6B3F93E44497FEFC22F101DA014BCF808F@imbpw2exd01.bosch-si.com>
References: <BDF7ED6B3F93E44497FEFC22F101DA014BCF808F@imbpw2exd01.bosch-si.com>
Message-ID: <CAJtn+Af-f52KEJ70wobbbhagTtn5WCtWx_GZ19=200xMwBp44w@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160308/12d93f3c/attachment.html 

From hugo.calado at gmail.com  Tue Mar  8 11:55:28 2016
From: hugo.calado at gmail.com (Hugo Calado)
Date: Tue, 8 Mar 2016 16:55:28 +0000
Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
Message-ID: <CAPxXGdMeAu_kKSNv69KYsDCs+ZVu01XB_ax4UiT4JfYxfGYCpA@mail.gmail.com>

Greetings,


How can i rewrite the path inside html files.

Original HTML file:

....<script type=*"text/javascript"* src=*"**/v/js/abc.js**"*></script>

After rewrite:

....<script type=*"text/javascript"* src=*"**/v123/js/abc.js**"*></script>

The main objective is to solve browser cache issues assuring that in each
new release the url's of static objects are modified,

Thank you,
Hugo Calado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160308/9ec8564a/attachment.html 

From sdouglas at redhat.com  Tue Mar  8 16:44:31 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 8 Mar 2016 16:44:31 -0500 (EST)
Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
In-Reply-To: <CAPxXGdMeAu_kKSNv69KYsDCs+ZVu01XB_ax4UiT4JfYxfGYCpA@mail.gmail.com>
References: <CAPxXGdMeAu_kKSNv69KYsDCs+ZVu01XB_ax4UiT4JfYxfGYCpA@mail.gmail.com>
Message-ID: <343459403.35963152.1457473471012.JavaMail.zimbra@redhat.com>

Are these simply static files, or dynamically generated?

Stuart

----- Original Message -----
> From: "Hugo Calado" <hugo.calado at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 9 March, 2016 3:55:28 AM
> Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
> 
> Greetings,
> 
> 
> How can i rewrite the path inside html files.
> 
> Original HTML file:
> 
> .... < script type = "text/javascript" src = " /v/js/abc.js " ></ script >
> 
> After rewrite:
> 
> .... < script type = "text/javascript" src = " /v123/js/abc.js " ></ script >
> 
> The main objective is to solve browser cache issues assuring that in each new
> release the url's of static objects are modified,
> 
> Thank you,
> Hugo Calado
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Tue Mar  8 18:35:12 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 8 Mar 2016 18:35:12 -0500 (EST)
Subject: [undertow-dev] Loss of perfomance between
	1.3.0.Beta9	and	1.3.18.Final
In-Reply-To: <1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
Message-ID: <1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>

Can you re-run but with the following setting:

.setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)

The default changed between these versions, so now idle connections will eventually be timed out (otherwise browsers can hold connections for a very time long which was causing people to have issues with FD exhaustion).

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Toby Crawley" <toby at tcrawley.org>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 7 March, 2016 10:59:27 AM
> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9	and	1.3.18.Final
> 
> This is not a known issue, I will investigate.
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Toby Crawley" <toby at tcrawley.org>
> > To: undertow-dev at lists.jboss.org
> > Sent: Saturday, 5 March, 2016 7:29:00 AM
> > Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> > 	1.3.18.Final
> > 
> > Is there a known decrease in throughput (measured with req/s)
> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
> > with Immutant, and were looking at upgrading to the latter in the next
> > release, but noticed a decrease in throughput with a simple Clojure
> > benchmark app.
> > 
> > I have replicated the basics of our benchmark app in Java[1], and saw a
> > decrease in req/s between the two versions of ~7% when testing with ab
> > and averaging the output of several runs.
> > 
> > Is there something that changed between those versions that is known
> > to have reduced performance?
> > 
> > - Toby
> > 
> > [1]: https://github.com/tobias/undertow-speed
> > _______________________________________________
> > 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 hugo.calado at gmail.com  Wed Mar  9 05:37:27 2016
From: hugo.calado at gmail.com (Hugo Calado)
Date: Wed, 9 Mar 2016 10:37:27 +0000
Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
In-Reply-To: <343459403.35963152.1457473471012.JavaMail.zimbra@redhat.com>
References: <CAPxXGdMeAu_kKSNv69KYsDCs+ZVu01XB_ax4UiT4JfYxfGYCpA@mail.gmail.com>
	<343459403.35963152.1457473471012.JavaMail.zimbra@redhat.com>
Message-ID: <CAPxXGdN5rXyu22cV=xcvfKesAksFLR6PgEzNVNMFz7MrDhwi4Q@mail.gmail.com>

Just static files.

Hugo

2016-03-08 21:44 GMT+00:00 Stuart Douglas <sdouglas at redhat.com>:

> Are these simply static files, or dynamically generated?
>
> Stuart
>
> ----- Original Message -----
> > From: "Hugo Calado" <hugo.calado at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 9 March, 2016 3:55:28 AM
> > Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
> >
> > Greetings,
> >
> >
> > How can i rewrite the path inside html files.
> >
> > Original HTML file:
> >
> > .... < script type = "text/javascript" src = " /v/js/abc.js " ></ script
> >
> >
> > After rewrite:
> >
> > .... < script type = "text/javascript" src = " /v123/js/abc.js " ></
> script >
> >
> > The main objective is to solve browser cache issues assuring that in
> each new
> > release the url's of static objects are modified,
> >
> > Thank you,
> > Hugo Calado
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20160309/e5391b37/attachment-0001.html 

From shivasaxena999 at gmail.com  Wed Mar  9 15:37:34 2016
From: shivasaxena999 at gmail.com (Shiva Saxena)
Date: Thu, 10 Mar 2016 02:07:34 +0530
Subject: [undertow-dev] java.lang.NoClassDefFoundError:
	freemarker/cache/TemplateLoader
In-Reply-To: <126196445.34426313.1457388867210.JavaMail.zimbra@redhat.com>
References: <CADjggukz48Pqhs5Wv3no=_n=qwXsYzo9dQMbx0p3g7S4ey0USQ@mail.gmail.com>
	<126196445.34426313.1457388867210.JavaMail.zimbra@redhat.com>
Message-ID: <CADjggunET1tn3twJuj6=18OvmezmRxZQVQSbUVUydS3Mb7cd9Q@mail.gmail.com>

Hi,

I did add the freemarker maven dependency in the project, and after the
build its there in the WEB-INF/lib folder too, yet the issue persists.

Am I missing the something, or something more is expected?

PS: The project can be found @
https://github.com/shivasaxena/undertow-js-example

On Tue, Mar 8, 2016 at 3:44 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Wildfly only bundles the mustache template library by default, if you want
> to use Freemarker you need to bundle it in your deployment.
>
> Stuart
>
> ----- Original Message -----
> > From: "Shiva Saxena" <shivasaxena999 at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Saturday, 5 March, 2016 9:51:06 PM
> > Subject: [undertow-dev] java.lang.NoClassDefFoundError:
>  freemarker/cache/TemplateLoader
> >
> > Hi,
> >
> > I am just creating a Hello world example of undertow.js like so
> >
> > $undertow
> > .onGet("/hello-freemarker",
> > {template: '/resources/hello.ftl','template_type': 'freemarker', headers:
> > {"content-type": "text/plain"}},
> > [function ($exchange) {
> > return {data: 'Hello World!'};
> > }]);
> > When deploying the project I am getting the following exception
> >
> > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2)
> > MSC000001: Failed to start service
> >
> jboss.undertow.deployment.default-server.default-host./undertowjs-example:
> > org.jboss.msc.service.StartException in service
> >
> jboss.undertow.deployment.default-server.default-host./undertowjs-example:
> > java.util.ServiceConfigurationError:
> > io.undertow.js.templates.TemplateProvider: Provider
> > io.undertow.js.templates.freemarker.FreemarkerTemplateProvider could not
> be
> > instantiated
> > at
> >
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > 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)
> >
> > I have also added the freemarker jar file in the modules folder but it
> still
> > doesn't help. Please let me know what I might be doing wrong or is come
> > extra conf required.
> >
> > --
> > Best Regards
> > Shiva Saxena
> > Mobile : +91-9889787094
> > Blog | Linkedin | StackOverflow
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Best Regards
*Shiva Saxena*
*Mobile : +91-9889787094                            *
*Blog <http://metalop.com/> | Linkedin
<http://in.linkedin.com/in/shivasaxena/> | StackOverflow
<http://stackoverflow.com/users/2490343/shiva>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160310/d8d41534/attachment.html 

From jim at crossleys.org  Wed Mar  9 16:10:47 2016
From: jim at crossleys.org (Jim Crossley)
Date: Wed, 9 Mar 2016 16:10:47 -0500
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
	1.3.18.Final
In-Reply-To: <1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
	<1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
Message-ID: <CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>

Hi Stuart,

Toby asked me to try on my machine, and I see an even bigger
throughput disparity. I'm using his test app:
https://github.com/tobias/undertow-speed

In one shell I run 'mvn clean compile exec:java' and in another I run
'./bench-avg.sh' and I get this output:

jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
Requests per second:    14717.03 [#/sec] (mean)
Requests per second:    14527.32 [#/sec] (mean)
Requests per second:    14288.32 [#/sec] (mean)
Requests per second:    14375.64 [#/sec] (mean)
Requests per second:    14653.08 [#/sec] (mean)
Average: 14512

Then I run 'mvn clean compile exec:java -Pbeta9' in the first shell
and re-run bench-avg.sh. I get this:

jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
Requests per second:    24069.72 [#/sec] (mean)
Requests per second:    25002.35 [#/sec] (mean)
Requests per second:    24885.36 [#/sec] (mean)
Requests per second:    25261.30 [#/sec] (mean)
Requests per second:    24800.82 [#/sec] (mean)
Average: 24803.4

As you can see, quite a bit more than 7%, beta9 yields almost 70%
better throughput for me!

I set the option you suggested for 1.3.18 and I get slightly better numbers:

jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
Requests per second:    15749.52 [#/sec] (mean)
Requests per second:    15309.83 [#/sec] (mean)
Requests per second:    15909.15 [#/sec] (mean)
Requests per second:    16228.10 [#/sec] (mean)
Requests per second:    16118.84 [#/sec] (mean)
Average: 15862.6

But nowhere close to beta9.

Can you clone his app and reproduce locally?

Thanks,
Jim


On Tue, Mar 8, 2016 at 6:35 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> Can you re-run but with the following setting:
>
> .setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)
>
> The default changed between these versions, so now idle connections will eventually be timed out (otherwise browsers can hold connections for a very time long which was causing people to have issues with FD exhaustion).
>
> Stuart
>
> ----- Original Message -----
>> From: "Stuart Douglas" <sdouglas at redhat.com>
>> To: "Toby Crawley" <toby at tcrawley.org>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Monday, 7 March, 2016 10:59:27 AM
>> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9    and     1.3.18.Final
>>
>> This is not a known issue, I will investigate.
>>
>> Stuart
>>
>> ----- Original Message -----
>> > From: "Toby Crawley" <toby at tcrawley.org>
>> > To: undertow-dev at lists.jboss.org
>> > Sent: Saturday, 5 March, 2016 7:29:00 AM
>> > Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
>> >     1.3.18.Final
>> >
>> > Is there a known decrease in throughput (measured with req/s)
>> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
>> > with Immutant, and were looking at upgrading to the latter in the next
>> > release, but noticed a decrease in throughput with a simple Clojure
>> > benchmark app.
>> >
>> > I have replicated the basics of our benchmark app in Java[1], and saw a
>> > decrease in req/s between the two versions of ~7% when testing with ab
>> > and averaging the output of several runs.
>> >
>> > Is there something that changed between those versions that is known
>> > to have reduced performance?
>> >
>> > - Toby
>> >
>> > [1]: https://github.com/tobias/undertow-speed
>> > _______________________________________________
>> > 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 anmiller at redhat.com  Wed Mar  9 16:28:37 2016
From: anmiller at redhat.com (Andrig T. Miller)
Date: Wed, 9 Mar 2016 16:28:37 -0500 (EST)
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9
	and	1.3.18.Final
In-Reply-To: <CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
	<1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
	<CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>
Message-ID: <1129790686.36535490.1457558917830.JavaMail.zimbra@redhat.com>

Stuart, 

I'm not sure what this undertow-speed app does, but I'm nervous that tuning for it, may undo some of the improvements we made in the performance lab. One thing I would suggest though, is using perf on Linux and creating a flamegraph for Beta9 and the Final. It's likely that some methods that were being inlined are no longer being inlined, and the flamegraphs and the underlying perf data will show that. In order to use perf you have to set the JVM parameter to preserve frame pointers: 

-XX:+PreserveFramePointer 

Ping anyone from the performance team, and they can help you with the setup of perf, and generating the flame graphs. 

Andy 

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

> Hi Stuart,

> Toby asked me to try on my machine, and I see an even bigger
> throughput disparity. I'm using his test app:
> https://github.com/tobias/undertow-speed

> In one shell I run 'mvn clean compile exec:java' and in another I run
> './bench-avg.sh' and I get this output:

> jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> Requests per second: 14717.03 [#/sec] (mean)
> Requests per second: 14527.32 [#/sec] (mean)
> Requests per second: 14288.32 [#/sec] (mean)
> Requests per second: 14375.64 [#/sec] (mean)
> Requests per second: 14653.08 [#/sec] (mean)
> Average: 14512

> Then I run 'mvn clean compile exec:java -Pbeta9' in the first shell
> and re-run bench-avg.sh. I get this:

> jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> Requests per second: 24069.72 [#/sec] (mean)
> Requests per second: 25002.35 [#/sec] (mean)
> Requests per second: 24885.36 [#/sec] (mean)
> Requests per second: 25261.30 [#/sec] (mean)
> Requests per second: 24800.82 [#/sec] (mean)
> Average: 24803.4

> As you can see, quite a bit more than 7%, beta9 yields almost 70%
> better throughput for me!

> I set the option you suggested for 1.3.18 and I get slightly better numbers:

> jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> Requests per second: 15749.52 [#/sec] (mean)
> Requests per second: 15309.83 [#/sec] (mean)
> Requests per second: 15909.15 [#/sec] (mean)
> Requests per second: 16228.10 [#/sec] (mean)
> Requests per second: 16118.84 [#/sec] (mean)
> Average: 15862.6

> But nowhere close to beta9.

> Can you clone his app and reproduce locally?

> Thanks,
> Jim

> On Tue, Mar 8, 2016 at 6:35 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> > Can you re-run but with the following setting:
> >
> > .setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)
> >
> > The default changed between these versions, so now idle connections will
> > eventually be timed out (otherwise browsers can hold connections for a
> > very time long which was causing people to have issues with FD
> > exhaustion).
> >
> > Stuart
> >
> > ----- Original Message -----
> >> From: "Stuart Douglas" <sdouglas at redhat.com>
> >> To: "Toby Crawley" <toby at tcrawley.org>
> >> Cc: undertow-dev at lists.jboss.org
> >> Sent: Monday, 7 March, 2016 10:59:27 AM
> >> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> >> 1.3.18.Final
> >>
> >> This is not a known issue, I will investigate.
> >>
> >> Stuart
> >>
> >> ----- Original Message -----
> >> > From: "Toby Crawley" <toby at tcrawley.org>
> >> > To: undertow-dev at lists.jboss.org
> >> > Sent: Saturday, 5 March, 2016 7:29:00 AM
> >> > Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> >> > 1.3.18.Final
> >> >
> >> > Is there a known decrease in throughput (measured with req/s)
> >> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
> >> > with Immutant, and were looking at upgrading to the latter in the next
> >> > release, but noticed a decrease in throughput with a simple Clojure
> >> > benchmark app.
> >> >
> >> > I have replicated the basics of our benchmark app in Java[1], and saw a
> >> > decrease in req/s between the two versions of ~7% when testing with ab
> >> > and averaging the output of several runs.
> >> >
> >> > Is there something that changed between those versions that is known
> >> > to have reduced performance?
> >> >
> >> > - Toby
> >> >
> >> > [1]: https://github.com/tobias/undertow-speed
> >> > _______________________________________________
> >> > 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
> _______________________________________________
> 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/20160309/c3177c2a/attachment-0001.html 

From sdouglas at redhat.com  Wed Mar  9 17:51:00 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 9 Mar 2016 17:51:00 -0500 (EST)
Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
In-Reply-To: <CAPxXGdN5rXyu22cV=xcvfKesAksFLR6PgEzNVNMFz7MrDhwi4Q@mail.gmail.com>
References: <CAPxXGdMeAu_kKSNv69KYsDCs+ZVu01XB_ax4UiT4JfYxfGYCpA@mail.gmail.com>
	<343459403.35963152.1457473471012.JavaMail.zimbra@redhat.com>
	<CAPxXGdN5rXyu22cV=xcvfKesAksFLR6PgEzNVNMFz7MrDhwi4Q@mail.gmail.com>
Message-ID: <1074178704.36742389.1457563860275.JavaMail.zimbra@redhat.com>

Why not just rewrite them at build time? It will be much more efficient than trying to do it every time you serve the file.

In general this is not an easy problem, you need to use a HTML parser to parse the page, modify it and then rewrite it, which will be slow (alternatively you could try hacking up something using regex's or similar, but it hard to make it work all the time). 

Stuart

----- Original Message -----
> From: "Hugo Calado" <hugo.calado at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Wednesday, 9 March, 2016 9:37:27 PM
> Subject: Re: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
> 
> Just static files.
> 
> Hugo
> 
> 2016-03-08 21:44 GMT+00:00 Stuart Douglas <sdouglas at redhat.com>:
> 
> > Are these simply static files, or dynamically generated?
> >
> > Stuart
> >
> > ----- Original Message -----
> > > From: "Hugo Calado" <hugo.calado at gmail.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Wednesday, 9 March, 2016 3:55:28 AM
> > > Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
> > >
> > > Greetings,
> > >
> > >
> > > How can i rewrite the path inside html files.
> > >
> > > Original HTML file:
> > >
> > > .... < script type = "text/javascript" src = " /v/js/abc.js " ></ script
> > >
> > >
> > > After rewrite:
> > >
> > > .... < script type = "text/javascript" src = " /v123/js/abc.js " ></
> > script >
> > >
> > > The main objective is to solve browser cache issues assuring that in
> > each new
> > > release the url's of static objects are modified,
> > >
> > > Thank you,
> > > Hugo Calado
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 

From sdouglas at redhat.com  Wed Mar  9 18:00:10 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 9 Mar 2016 18:00:10 -0500 (EST)
Subject: [undertow-dev] java.lang.NoClassDefFoundError:
 freemarker/cache/TemplateLoader
In-Reply-To: <CADjggunET1tn3twJuj6=18OvmezmRxZQVQSbUVUydS3Mb7cd9Q@mail.gmail.com>
References: <CADjggukz48Pqhs5Wv3no=_n=qwXsYzo9dQMbx0p3g7S4ey0USQ@mail.gmail.com>
	<126196445.34426313.1457388867210.JavaMail.zimbra@redhat.com>
	<CADjggunET1tn3twJuj6=18OvmezmRxZQVQSbUVUydS3Mb7cd9Q@mail.gmail.com>
Message-ID: <169412068.36744060.1457564410798.JavaMail.zimbra@redhat.com>

Hmm, this looks like a bug, I have created https://issues.jboss.org/browse/WFLY-6346

For now if you want to use freemarker you would need to add the jar to the modules/system/layers/base/io/undertow/js/main/ folder (and the corresponding module.xml).

Stuart

----- Original Message -----
> From: "Shiva Saxena" <shivasaxena999 at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Thursday, 10 March, 2016 7:37:34 AM
> Subject: Re: [undertow-dev] java.lang.NoClassDefFoundError: freemarker/cache/TemplateLoader
> 
> Hi,
> 
> I did add the freemarker maven dependency in the project, and after the
> build its there in the WEB-INF/lib folder too, yet the issue persists.
> 
> Am I missing the something, or something more is expected?
> 
> PS: The project can be found @
> https://github.com/shivasaxena/undertow-js-example
> 
> On Tue, Mar 8, 2016 at 3:44 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> > Wildfly only bundles the mustache template library by default, if you want
> > to use Freemarker you need to bundle it in your deployment.
> >
> > Stuart
> >
> > ----- Original Message -----
> > > From: "Shiva Saxena" <shivasaxena999 at gmail.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Saturday, 5 March, 2016 9:51:06 PM
> > > Subject: [undertow-dev] java.lang.NoClassDefFoundError:
> >  freemarker/cache/TemplateLoader
> > >
> > > Hi,
> > >
> > > I am just creating a Hello world example of undertow.js like so
> > >
> > > $undertow
> > > .onGet("/hello-freemarker",
> > > {template: '/resources/hello.ftl','template_type': 'freemarker', headers:
> > > {"content-type": "text/plain"}},
> > > [function ($exchange) {
> > > return {data: 'Hello World!'};
> > > }]);
> > > When deploying the project I am getting the following exception
> > >
> > > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2)
> > > MSC000001: Failed to start service
> > >
> > jboss.undertow.deployment.default-server.default-host./undertowjs-example:
> > > org.jboss.msc.service.StartException in service
> > >
> > jboss.undertow.deployment.default-server.default-host./undertowjs-example:
> > > java.util.ServiceConfigurationError:
> > > io.undertow.js.templates.TemplateProvider: Provider
> > > io.undertow.js.templates.freemarker.FreemarkerTemplateProvider could not
> > be
> > > instantiated
> > > at
> > >
> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> > > at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> > > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > > 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)
> > >
> > > I have also added the freemarker jar file in the modules folder but it
> > still
> > > doesn't help. Please let me know what I might be doing wrong or is come
> > > extra conf required.
> > >
> > > --
> > > Best Regards
> > > Shiva Saxena
> > > Mobile : +91-9889787094
> > > Blog | Linkedin | StackOverflow
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 
> 
> 
> --
> Best Regards
> *Shiva Saxena*
> *Mobile : +91-9889787094                            *
> *Blog <http://metalop.com/> | Linkedin
> <http://in.linkedin.com/in/shivasaxena/> | StackOverflow
> <http://stackoverflow.com/users/2490343/shiva>*
> 

From miere.teixeira at gmail.com  Wed Mar  9 19:20:41 2016
From: miere.teixeira at gmail.com (Miere Teixeira)
Date: Thu, 10 Mar 2016 00:20:41 +0000
Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
In-Reply-To: <1074178704.36742389.1457563860275.JavaMail.zimbra@redhat.com>
References: <CAPxXGdMeAu_kKSNv69KYsDCs+ZVu01XB_ax4UiT4JfYxfGYCpA@mail.gmail.com>
	<343459403.35963152.1457473471012.JavaMail.zimbra@redhat.com>
	<CAPxXGdN5rXyu22cV=xcvfKesAksFLR6PgEzNVNMFz7MrDhwi4Q@mail.gmail.com>
	<1074178704.36742389.1457563860275.JavaMail.zimbra@redhat.com>
Message-ID: <CAHezjrTxbCQCwpkjtrrr0PgpYUTwvWCdsFVpsfUEKUR0uMD+pw@mail.gmail.com>

I'd suggest you to create a random token (or any minor release number) and
store it at the build time. Then, use it as a query parameter on your
asset... Something like this:

<link rel="stylesheet" href="/css/theme.css
<http://localhost:9090/css/theme.css>?yourTokenWillBeHere" />

Last, but not the least, use a template engine like JMustache
<https://github.com/samskivert/jmustache> or Freemarker to this. They used
to be versatile enough to handle HTML rendering and offers a nice API to
define template variables.

I'm sure there must be an easier approach, like Grails used to do, but I
think this would be good enough.


On Wed, Mar 9, 2016 at 7:51 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> Why not just rewrite them at build time? It will be much more efficient
> than trying to do it every time you serve the file.
>
> In general this is not an easy problem, you need to use a HTML parser to
> parse the page, modify it and then rewrite it, which will be slow
> (alternatively you could try hacking up something using regex's or similar,
> but it hard to make it work all the time).
>
> Stuart
>
> ----- Original Message -----
> > From: "Hugo Calado" <hugo.calado at gmail.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 9 March, 2016 9:37:27 PM
> > Subject: Re: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
> >
> > Just static files.
> >
> > Hugo
> >
> > 2016-03-08 21:44 GMT+00:00 Stuart Douglas <sdouglas at redhat.com>:
> >
> > > Are these simply static files, or dynamically generated?
> > >
> > > Stuart
> > >
> > > ----- Original Message -----
> > > > From: "Hugo Calado" <hugo.calado at gmail.com>
> > > > To: undertow-dev at lists.jboss.org
> > > > Sent: Wednesday, 9 March, 2016 3:55:28 AM
> > > > Subject: [undertow-dev] Undertow 1.3.0 - rewrite HTML content
> > > >
> > > > Greetings,
> > > >
> > > >
> > > > How can i rewrite the path inside html files.
> > > >
> > > > Original HTML file:
> > > >
> > > > .... < script type = "text/javascript" src = " /v/js/abc.js " ></
> script
> > > >
> > > >
> > > > After rewrite:
> > > >
> > > > .... < script type = "text/javascript" src = " /v123/js/abc.js " ></
> > > script >
> > > >
> > > > The main objective is to solve browser cache issues assuring that in
> > > each new
> > > > release the url's of static objects are modified,
> > > >
> > > > Thank you,
> > > > Hugo Calado
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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/20160310/6999736e/attachment.html 

From sdouglas at redhat.com  Wed Mar  9 20:49:31 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 9 Mar 2016 20:49:31 -0500 (EST)
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9
	and	1.3.18.Final
In-Reply-To: <1129790686.36535490.1457558917830.JavaMail.zimbra@redhat.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
	<1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
	<CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>
	<1129790686.36535490.1457558917830.JavaMail.zimbra@redhat.com>
Message-ID: <1303924517.36786309.1457574571266.JavaMail.zimbra@redhat.com>


TLDR: Looks like there is a problem in XNIO accept handling, I have submitted a PR, after my PR it should be considerably faster than Beta9 (at least on my machine). This problem only affects non-persistent connections.



I have looked into this a bit more, I have done some testing on my linux machine (4 core CentOS).

Running the benchmark as described with the NO_REQUEST_TIMEOUT set to -1 I get:

Beta9:          23031
1.3.18.Final:   22578 

However adding -k to the ab command to use persistent connections gives a different result:

Beta9:        169100
1.3.18.Final  173462

This implies that the issue is only with non persistent connections. Something that did change between Beta9 and 1.3.18.Final is XNIO connection handling, which has been changed to use a dedicated accept thread. Looking into this I have noticed a potential problem that is causing contention. I have submitted a fix at https://github.com/xnio/xnio/pull/94.

Something else to note is that ab was 100% maxed out on a CPU core when running these tests. In general ab is not a great load driver as it is single threaded.

The results get much more interesting if you modify the bench.sh slightly by adding an '&' to the end of the ab line and removing the 'sleep 5' call. This makes all 5 ab instances run at once, which is enough to max out the CPU on my machine (I also multiplied the number of requests by 5, the current number is a bit low).

Using this approach I get the following results (3.3.6.Final-SNAPSHOT includes the PR I linked above):

Non persistent connections:

Beta9:                                    8,810
1.3.18.Final:                             6,578
1.3.18.Final + XNIO 3.3.6.Final-SNAPSHOT: 10,285

When under heavy load the accept thread approach performs much better than the old approach (which was what we saw in Specj), however the XNIO bug was causing problems.

Jim, because you saw a much greater performance loss that I did would you be able to re-run some of these tests with my XNIO changes and verify that this also fixes the issue for you (ideally using multiple ab instances to really load the machine)? If there are still problems I would like to know what sort of hardware you are seeing this on.


Stuart




----- Original Message -----
> From: "Andrig T. Miller" <anmiller at redhat.com>
> To: "Jim Crossley" <jim at crossleys.org>
> Cc: "Stuart Douglas" <sdouglas at redhat.com>, undertow-dev at lists.jboss.org
> Sent: Thursday, 10 March, 2016 8:28:37 AM
> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and	1.3.18.Final
> 
> Stuart,
> 
> I'm not sure what this undertow-speed app does, but I'm nervous that tuning
> for it, may undo some of the improvements we made in the performance lab.
> One thing I would suggest though, is using perf on Linux and creating a
> flamegraph for Beta9 and the Final. It's likely that some methods that were
> being inlined are no longer being inlined, and the flamegraphs and the
> underlying perf data will show that. In order to use perf you have to set
> the JVM parameter to preserve frame pointers:
> 
> -XX:+PreserveFramePointer
> 
> Ping anyone from the performance team, and they can help you with the setup
> of perf, and generating the flame graphs.
> 
> Andy
> 
> ----- Original Message -----
> 
> > Hi Stuart,
> 
> > Toby asked me to try on my machine, and I see an even bigger
> > throughput disparity. I'm using his test app:
> > https://github.com/tobias/undertow-speed
> 
> > In one shell I run 'mvn clean compile exec:java' and in another I run
> > './bench-avg.sh' and I get this output:
> 
> > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > Requests per second: 14717.03 [#/sec] (mean)
> > Requests per second: 14527.32 [#/sec] (mean)
> > Requests per second: 14288.32 [#/sec] (mean)
> > Requests per second: 14375.64 [#/sec] (mean)
> > Requests per second: 14653.08 [#/sec] (mean)
> > Average: 14512
> 
> > Then I run 'mvn clean compile exec:java -Pbeta9' in the first shell
> > and re-run bench-avg.sh. I get this:
> 
> > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > Requests per second: 24069.72 [#/sec] (mean)
> > Requests per second: 25002.35 [#/sec] (mean)
> > Requests per second: 24885.36 [#/sec] (mean)
> > Requests per second: 25261.30 [#/sec] (mean)
> > Requests per second: 24800.82 [#/sec] (mean)
> > Average: 24803.4
> 
> > As you can see, quite a bit more than 7%, beta9 yields almost 70%
> > better throughput for me!
> 
> > I set the option you suggested for 1.3.18 and I get slightly better
> > numbers:
> 
> > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > Requests per second: 15749.52 [#/sec] (mean)
> > Requests per second: 15309.83 [#/sec] (mean)
> > Requests per second: 15909.15 [#/sec] (mean)
> > Requests per second: 16228.10 [#/sec] (mean)
> > Requests per second: 16118.84 [#/sec] (mean)
> > Average: 15862.6
> 
> > But nowhere close to beta9.
> 
> > Can you clone his app and reproduce locally?
> 
> > Thanks,
> > Jim
> 
> > On Tue, Mar 8, 2016 at 6:35 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> > > Can you re-run but with the following setting:
> > >
> > > .setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)
> > >
> > > The default changed between these versions, so now idle connections will
> > > eventually be timed out (otherwise browsers can hold connections for a
> > > very time long which was causing people to have issues with FD
> > > exhaustion).
> > >
> > > Stuart
> > >
> > > ----- Original Message -----
> > >> From: "Stuart Douglas" <sdouglas at redhat.com>
> > >> To: "Toby Crawley" <toby at tcrawley.org>
> > >> Cc: undertow-dev at lists.jboss.org
> > >> Sent: Monday, 7 March, 2016 10:59:27 AM
> > >> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> > >> 1.3.18.Final
> > >>
> > >> This is not a known issue, I will investigate.
> > >>
> > >> Stuart
> > >>
> > >> ----- Original Message -----
> > >> > From: "Toby Crawley" <toby at tcrawley.org>
> > >> > To: undertow-dev at lists.jboss.org
> > >> > Sent: Saturday, 5 March, 2016 7:29:00 AM
> > >> > Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> > >> > 1.3.18.Final
> > >> >
> > >> > Is there a known decrease in throughput (measured with req/s)
> > >> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
> > >> > with Immutant, and were looking at upgrading to the latter in the next
> > >> > release, but noticed a decrease in throughput with a simple Clojure
> > >> > benchmark app.
> > >> >
> > >> > I have replicated the basics of our benchmark app in Java[1], and saw
> > >> > a
> > >> > decrease in req/s between the two versions of ~7% when testing with ab
> > >> > and averaging the output of several runs.
> > >> >
> > >> > Is there something that changed between those versions that is known
> > >> > to have reduced performance?
> > >> >
> > >> > - Toby
> > >> >
> > >> > [1]: https://github.com/tobias/undertow-speed
> > >> > _______________________________________________
> > >> > 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
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From jim at crossleys.org  Thu Mar 10 10:02:38 2016
From: jim at crossleys.org (Jim Crossley)
Date: Thu, 10 Mar 2016 10:02:38 -0500
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
	1.3.18.Final
In-Reply-To: <1303924517.36786309.1457574571266.JavaMail.zimbra@redhat.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
	<1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
	<CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>
	<1129790686.36535490.1457558917830.JavaMail.zimbra@redhat.com>
	<1303924517.36786309.1457574571266.JavaMail.zimbra@redhat.com>
Message-ID: <CACMdBJCB+xZ8zGRdZVGtka_DCeAZc4phRxj5kz0o12owCJZ2pQ@mail.gmail.com>

Hi Stuart,

Your fix definitely has an impact. Here's what I'm seeing:

Serial ab (unmodified bench.sh), non-persistent connections:

Beta9:                                   25229
1.3.18.Final:                            16007
1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT:  23153

Parallel ab, non-persistent connections:

Beta9:                                    3740
1.3.18.Final:                             2447
1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT:   6675

Serial ab, persistent connections (-k option):

Beta9:                                  108847
1.3.18.Final:                           106262
1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT: 107984

My numbers are lower than yours. My hardware is a quad core Lenovo T430s
running Linux 3.13.0-37-generic x86_64... due to be replaced in May ;)

Thanks,
Jim

On Wed, Mar 9, 2016 at 8:49 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

>
> TLDR: Looks like there is a problem in XNIO accept handling, I have
> submitted a PR, after my PR it should be considerably faster than Beta9 (at
> least on my machine). This problem only affects non-persistent connections.
>
>
>
> I have looked into this a bit more, I have done some testing on my linux
> machine (4 core CentOS).
>
> Running the benchmark as described with the NO_REQUEST_TIMEOUT set to -1 I
> get:
>
> Beta9:          23031
> 1.3.18.Final:   22578
>
> However adding -k to the ab command to use persistent connections gives a
> different result:
>
> Beta9:        169100
> 1.3.18.Final  173462
>
> This implies that the issue is only with non persistent connections.
> Something that did change between Beta9 and 1.3.18.Final is XNIO connection
> handling, which has been changed to use a dedicated accept thread. Looking
> into this I have noticed a potential problem that is causing contention. I
> have submitted a fix at https://github.com/xnio/xnio/pull/94.
>
> Something else to note is that ab was 100% maxed out on a CPU core when
> running these tests. In general ab is not a great load driver as it is
> single threaded.
>
> The results get much more interesting if you modify the bench.sh slightly
> by adding an '&' to the end of the ab line and removing the 'sleep 5' call.
> This makes all 5 ab instances run at once, which is enough to max out the
> CPU on my machine (I also multiplied the number of requests by 5, the
> current number is a bit low).
>
> Using this approach I get the following results (3.3.6.Final-SNAPSHOT
> includes the PR I linked above):
>
> Non persistent connections:
>
> Beta9:                                    8,810
> 1.3.18.Final:                             6,578
> 1.3.18.Final + XNIO 3.3.6.Final-SNAPSHOT: 10,285
>
> When under heavy load the accept thread approach performs much better than
> the old approach (which was what we saw in Specj), however the XNIO bug was
> causing problems.
>
> Jim, because you saw a much greater performance loss that I did would you
> be able to re-run some of these tests with my XNIO changes and verify that
> this also fixes the issue for you (ideally using multiple ab instances to
> really load the machine)? If there are still problems I would like to know
> what sort of hardware you are seeing this on.
>
>
> Stuart
>
>
>
>
> ----- Original Message -----
> > From: "Andrig T. Miller" <anmiller at redhat.com>
> > To: "Jim Crossley" <jim at crossleys.org>
> > Cc: "Stuart Douglas" <sdouglas at redhat.com>, undertow-dev at lists.jboss.org
> > Sent: Thursday, 10 March, 2016 8:28:37 AM
> > Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
>       1.3.18.Final
> >
> > Stuart,
> >
> > I'm not sure what this undertow-speed app does, but I'm nervous that
> tuning
> > for it, may undo some of the improvements we made in the performance lab.
> > One thing I would suggest though, is using perf on Linux and creating a
> > flamegraph for Beta9 and the Final. It's likely that some methods that
> were
> > being inlined are no longer being inlined, and the flamegraphs and the
> > underlying perf data will show that. In order to use perf you have to set
> > the JVM parameter to preserve frame pointers:
> >
> > -XX:+PreserveFramePointer
> >
> > Ping anyone from the performance team, and they can help you with the
> setup
> > of perf, and generating the flame graphs.
> >
> > Andy
> >
> > ----- Original Message -----
> >
> > > Hi Stuart,
> >
> > > Toby asked me to try on my machine, and I see an even bigger
> > > throughput disparity. I'm using his test app:
> > > https://github.com/tobias/undertow-speed
> >
> > > In one shell I run 'mvn clean compile exec:java' and in another I run
> > > './bench-avg.sh' and I get this output:
> >
> > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > Requests per second: 14717.03 [#/sec] (mean)
> > > Requests per second: 14527.32 [#/sec] (mean)
> > > Requests per second: 14288.32 [#/sec] (mean)
> > > Requests per second: 14375.64 [#/sec] (mean)
> > > Requests per second: 14653.08 [#/sec] (mean)
> > > Average: 14512
> >
> > > Then I run 'mvn clean compile exec:java -Pbeta9' in the first shell
> > > and re-run bench-avg.sh. I get this:
> >
> > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > Requests per second: 24069.72 [#/sec] (mean)
> > > Requests per second: 25002.35 [#/sec] (mean)
> > > Requests per second: 24885.36 [#/sec] (mean)
> > > Requests per second: 25261.30 [#/sec] (mean)
> > > Requests per second: 24800.82 [#/sec] (mean)
> > > Average: 24803.4
> >
> > > As you can see, quite a bit more than 7%, beta9 yields almost 70%
> > > better throughput for me!
> >
> > > I set the option you suggested for 1.3.18 and I get slightly better
> > > numbers:
> >
> > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > Requests per second: 15749.52 [#/sec] (mean)
> > > Requests per second: 15309.83 [#/sec] (mean)
> > > Requests per second: 15909.15 [#/sec] (mean)
> > > Requests per second: 16228.10 [#/sec] (mean)
> > > Requests per second: 16118.84 [#/sec] (mean)
> > > Average: 15862.6
> >
> > > But nowhere close to beta9.
> >
> > > Can you clone his app and reproduce locally?
> >
> > > Thanks,
> > > Jim
> >
> > > On Tue, Mar 8, 2016 at 6:35 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> > > > Can you re-run but with the following setting:
> > > >
> > > > .setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)
> > > >
> > > > The default changed between these versions, so now idle connections
> will
> > > > eventually be timed out (otherwise browsers can hold connections for
> a
> > > > very time long which was causing people to have issues with FD
> > > > exhaustion).
> > > >
> > > > Stuart
> > > >
> > > > ----- Original Message -----
> > > >> From: "Stuart Douglas" <sdouglas at redhat.com>
> > > >> To: "Toby Crawley" <toby at tcrawley.org>
> > > >> Cc: undertow-dev at lists.jboss.org
> > > >> Sent: Monday, 7 March, 2016 10:59:27 AM
> > > >> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9
> and
> > > >> 1.3.18.Final
> > > >>
> > > >> This is not a known issue, I will investigate.
> > > >>
> > > >> Stuart
> > > >>
> > > >> ----- Original Message -----
> > > >> > From: "Toby Crawley" <toby at tcrawley.org>
> > > >> > To: undertow-dev at lists.jboss.org
> > > >> > Sent: Saturday, 5 March, 2016 7:29:00 AM
> > > >> > Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> > > >> > 1.3.18.Final
> > > >> >
> > > >> > Is there a known decrease in throughput (measured with req/s)
> > > >> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
> > > >> > with Immutant, and were looking at upgrading to the latter in the
> next
> > > >> > release, but noticed a decrease in throughput with a simple
> Clojure
> > > >> > benchmark app.
> > > >> >
> > > >> > I have replicated the basics of our benchmark app in Java[1], and
> saw
> > > >> > a
> > > >> > decrease in req/s between the two versions of ~7% when testing
> with ab
> > > >> > and averaging the output of several runs.
> > > >> >
> > > >> > Is there something that changed between those versions that is
> known
> > > >> > to have reduced performance?
> > > >> >
> > > >> > - Toby
> > > >> >
> > > >> > [1]: https://github.com/tobias/undertow-speed
> > > >> > _______________________________________________
> > > >> > 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
> > > _______________________________________________
> > > 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/20160310/1d154622/attachment.html 

From sdouglas at redhat.com  Thu Mar 10 16:29:38 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 10 Mar 2016 16:29:38 -0500 (EST)
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
 1.3.18.Final
In-Reply-To: <CACMdBJCB+xZ8zGRdZVGtka_DCeAZc4phRxj5kz0o12owCJZ2pQ@mail.gmail.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
	<1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
	<CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>
	<1129790686.36535490.1457558917830.JavaMail.zimbra@redhat.com>
	<1303924517.36786309.1457574571266.JavaMail.zimbra@redhat.com>
	<CACMdBJCB+xZ8zGRdZVGtka_DCeAZc4phRxj5kz0o12owCJZ2pQ@mail.gmail.com>
Message-ID: <1647553543.37634271.1457645378197.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jim Crossley" <jim at crossleys.org>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: "Andrig T. Miller" <anmiller at redhat.com>, undertow-dev at lists.jboss.org
> Sent: Friday, 11 March, 2016 2:02:38 AM
> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and 1.3.18.Final
> 
> Hi Stuart,
> 
> Your fix definitely has an impact. Here's what I'm seeing:
> 
> Serial ab (unmodified bench.sh), non-persistent connections:
> 
> Beta9:                                   25229
> 1.3.18.Final:                            16007
> 1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT:  23153

I am not to worried about the serial numbers. The way ab generates load in this instance is not really representative of the real world as it basically can only generate a single request at a time. It may be that the old approach gives better results for this type of workload.

> 
> Parallel ab, non-persistent connections:
> 
> Beta9:                                    3740
> 1.3.18.Final:                             2447
> 1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT:   6675

This looks much better. 

> 
> Serial ab, persistent connections (-k option):
> 
> Beta9:                                  108847
> 1.3.18.Final:                           106262
> 1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT: 107984

How many requests were you running for this test? In general to get stable numbers for persistent connections you should use more requests (as they run much faster).

Stuart


> 
> My numbers are lower than yours. My hardware is a quad core Lenovo T430s
> running Linux 3.13.0-37-generic x86_64... due to be replaced in May ;)
> 
> Thanks,
> Jim
> 
> On Wed, Mar 9, 2016 at 8:49 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> >
> > TLDR: Looks like there is a problem in XNIO accept handling, I have
> > submitted a PR, after my PR it should be considerably faster than Beta9 (at
> > least on my machine). This problem only affects non-persistent connections.
> >
> >
> >
> > I have looked into this a bit more, I have done some testing on my linux
> > machine (4 core CentOS).
> >
> > Running the benchmark as described with the NO_REQUEST_TIMEOUT set to -1 I
> > get:
> >
> > Beta9:          23031
> > 1.3.18.Final:   22578
> >
> > However adding -k to the ab command to use persistent connections gives a
> > different result:
> >
> > Beta9:        169100
> > 1.3.18.Final  173462
> >
> > This implies that the issue is only with non persistent connections.
> > Something that did change between Beta9 and 1.3.18.Final is XNIO connection
> > handling, which has been changed to use a dedicated accept thread. Looking
> > into this I have noticed a potential problem that is causing contention. I
> > have submitted a fix at https://github.com/xnio/xnio/pull/94.
> >
> > Something else to note is that ab was 100% maxed out on a CPU core when
> > running these tests. In general ab is not a great load driver as it is
> > single threaded.
> >
> > The results get much more interesting if you modify the bench.sh slightly
> > by adding an '&' to the end of the ab line and removing the 'sleep 5' call.
> > This makes all 5 ab instances run at once, which is enough to max out the
> > CPU on my machine (I also multiplied the number of requests by 5, the
> > current number is a bit low).
> >
> > Using this approach I get the following results (3.3.6.Final-SNAPSHOT
> > includes the PR I linked above):
> >
> > Non persistent connections:
> >
> > Beta9:                                    8,810
> > 1.3.18.Final:                             6,578
> > 1.3.18.Final + XNIO 3.3.6.Final-SNAPSHOT: 10,285
> >
> > When under heavy load the accept thread approach performs much better than
> > the old approach (which was what we saw in Specj), however the XNIO bug was
> > causing problems.
> >
> > Jim, because you saw a much greater performance loss that I did would you
> > be able to re-run some of these tests with my XNIO changes and verify that
> > this also fixes the issue for you (ideally using multiple ab instances to
> > really load the machine)? If there are still problems I would like to know
> > what sort of hardware you are seeing this on.
> >
> >
> > Stuart
> >
> >
> >
> >
> > ----- Original Message -----
> > > From: "Andrig T. Miller" <anmiller at redhat.com>
> > > To: "Jim Crossley" <jim at crossleys.org>
> > > Cc: "Stuart Douglas" <sdouglas at redhat.com>, undertow-dev at lists.jboss.org
> > > Sent: Thursday, 10 March, 2016 8:28:37 AM
> > > Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> >       1.3.18.Final
> > >
> > > Stuart,
> > >
> > > I'm not sure what this undertow-speed app does, but I'm nervous that
> > tuning
> > > for it, may undo some of the improvements we made in the performance lab.
> > > One thing I would suggest though, is using perf on Linux and creating a
> > > flamegraph for Beta9 and the Final. It's likely that some methods that
> > were
> > > being inlined are no longer being inlined, and the flamegraphs and the
> > > underlying perf data will show that. In order to use perf you have to set
> > > the JVM parameter to preserve frame pointers:
> > >
> > > -XX:+PreserveFramePointer
> > >
> > > Ping anyone from the performance team, and they can help you with the
> > setup
> > > of perf, and generating the flame graphs.
> > >
> > > Andy
> > >
> > > ----- Original Message -----
> > >
> > > > Hi Stuart,
> > >
> > > > Toby asked me to try on my machine, and I see an even bigger
> > > > throughput disparity. I'm using his test app:
> > > > https://github.com/tobias/undertow-speed
> > >
> > > > In one shell I run 'mvn clean compile exec:java' and in another I run
> > > > './bench-avg.sh' and I get this output:
> > >
> > > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > > Requests per second: 14717.03 [#/sec] (mean)
> > > > Requests per second: 14527.32 [#/sec] (mean)
> > > > Requests per second: 14288.32 [#/sec] (mean)
> > > > Requests per second: 14375.64 [#/sec] (mean)
> > > > Requests per second: 14653.08 [#/sec] (mean)
> > > > Average: 14512
> > >
> > > > Then I run 'mvn clean compile exec:java -Pbeta9' in the first shell
> > > > and re-run bench-avg.sh. I get this:
> > >
> > > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > > Requests per second: 24069.72 [#/sec] (mean)
> > > > Requests per second: 25002.35 [#/sec] (mean)
> > > > Requests per second: 24885.36 [#/sec] (mean)
> > > > Requests per second: 25261.30 [#/sec] (mean)
> > > > Requests per second: 24800.82 [#/sec] (mean)
> > > > Average: 24803.4
> > >
> > > > As you can see, quite a bit more than 7%, beta9 yields almost 70%
> > > > better throughput for me!
> > >
> > > > I set the option you suggested for 1.3.18 and I get slightly better
> > > > numbers:
> > >
> > > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > > Requests per second: 15749.52 [#/sec] (mean)
> > > > Requests per second: 15309.83 [#/sec] (mean)
> > > > Requests per second: 15909.15 [#/sec] (mean)
> > > > Requests per second: 16228.10 [#/sec] (mean)
> > > > Requests per second: 16118.84 [#/sec] (mean)
> > > > Average: 15862.6
> > >
> > > > But nowhere close to beta9.
> > >
> > > > Can you clone his app and reproduce locally?
> > >
> > > > Thanks,
> > > > Jim
> > >
> > > > On Tue, Mar 8, 2016 at 6:35 PM, Stuart Douglas <sdouglas at redhat.com>
> > wrote:
> > > > > Can you re-run but with the following setting:
> > > > >
> > > > > .setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)
> > > > >
> > > > > The default changed between these versions, so now idle connections
> > will
> > > > > eventually be timed out (otherwise browsers can hold connections for
> > a
> > > > > very time long which was causing people to have issues with FD
> > > > > exhaustion).
> > > > >
> > > > > Stuart
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > >> To: "Toby Crawley" <toby at tcrawley.org>
> > > > >> Cc: undertow-dev at lists.jboss.org
> > > > >> Sent: Monday, 7 March, 2016 10:59:27 AM
> > > > >> Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9
> > and
> > > > >> 1.3.18.Final
> > > > >>
> > > > >> This is not a known issue, I will investigate.
> > > > >>
> > > > >> Stuart
> > > > >>
> > > > >> ----- Original Message -----
> > > > >> > From: "Toby Crawley" <toby at tcrawley.org>
> > > > >> > To: undertow-dev at lists.jboss.org
> > > > >> > Sent: Saturday, 5 March, 2016 7:29:00 AM
> > > > >> > Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
> > > > >> > 1.3.18.Final
> > > > >> >
> > > > >> > Is there a known decrease in throughput (measured with req/s)
> > > > >> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the former
> > > > >> > with Immutant, and were looking at upgrading to the latter in the
> > next
> > > > >> > release, but noticed a decrease in throughput with a simple
> > Clojure
> > > > >> > benchmark app.
> > > > >> >
> > > > >> > I have replicated the basics of our benchmark app in Java[1], and
> > saw
> > > > >> > a
> > > > >> > decrease in req/s between the two versions of ~7% when testing
> > with ab
> > > > >> > and averaging the output of several runs.
> > > > >> >
> > > > >> > Is there something that changed between those versions that is
> > known
> > > > >> > to have reduced performance?
> > > > >> >
> > > > >> > - Toby
> > > > >> >
> > > > >> > [1]: https://github.com/tobias/undertow-speed
> > > > >> > _______________________________________________
> > > > >> > 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
> > > > _______________________________________________
> > > > undertow-dev mailing list
> > > > undertow-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > >
> >
> 

From jim at crossleys.org  Thu Mar 10 16:55:55 2016
From: jim at crossleys.org (Jim Crossley)
Date: Thu, 10 Mar 2016 16:55:55 -0500
Subject: [undertow-dev] Loss of perfomance between 1.3.0.Beta9 and
	1.3.18.Final
In-Reply-To: <1647553543.37634271.1457645378197.JavaMail.zimbra@redhat.com>
References: <CAA3HuyaKiBFPOed3GUqd43J8Sb9exs4_QX0xTn--ocPAgwE4sw@mail.gmail.com>
	<1588266851.33915849.1457308767120.JavaMail.zimbra@redhat.com>
	<1054680715.36004796.1457480112438.JavaMail.zimbra@redhat.com>
	<CACMdBJBz4u+eTn2LeV6GTtqsVuJAEYL5W-FtcqGz5UGVUdrZCw@mail.gmail.com>
	<1129790686.36535490.1457558917830.JavaMail.zimbra@redhat.com>
	<1303924517.36786309.1457574571266.JavaMail.zimbra@redhat.com>
	<CACMdBJCB+xZ8zGRdZVGtka_DCeAZc4phRxj5kz0o12owCJZ2pQ@mail.gmail.com>
	<1647553543.37634271.1457645378197.JavaMail.zimbra@redhat.com>
Message-ID: <CACMdBJA01fC4QpYXXPBG_LofhXVKcB1QLzmkqLQkU5H=5E5CCg@mail.gmail.com>

On Thu, Mar 10, 2016 at 4:29 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

>
> > Serial ab, persistent connections (-k option):
> >
> > Beta9:                                  108847
> > 1.3.18.Final:                           106262
> > 1.3.18.Final+XNIO 3.3.6.Final-SNAPSHOT: 107984
>
> How many requests were you running for this test? In general to get stable
> numbers for persistent connections you should use more requests (as they
> run much faster).
>
>
The original value in bench.sh: 100K. I just tried 500K and it yielded
about the same number.

Jim


> Stuart
>
>
> >
> > My numbers are lower than yours. My hardware is a quad core Lenovo T430s
> > running Linux 3.13.0-37-generic x86_64... due to be replaced in May ;)
> >
> > Thanks,
> > Jim
> >
> > On Wed, Mar 9, 2016 at 8:49 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >
> > >
> > > TLDR: Looks like there is a problem in XNIO accept handling, I have
> > > submitted a PR, after my PR it should be considerably faster than
> Beta9 (at
> > > least on my machine). This problem only affects non-persistent
> connections.
> > >
> > >
> > >
> > > I have looked into this a bit more, I have done some testing on my
> linux
> > > machine (4 core CentOS).
> > >
> > > Running the benchmark as described with the NO_REQUEST_TIMEOUT set to
> -1 I
> > > get:
> > >
> > > Beta9:          23031
> > > 1.3.18.Final:   22578
> > >
> > > However adding -k to the ab command to use persistent connections
> gives a
> > > different result:
> > >
> > > Beta9:        169100
> > > 1.3.18.Final  173462
> > >
> > > This implies that the issue is only with non persistent connections.
> > > Something that did change between Beta9 and 1.3.18.Final is XNIO
> connection
> > > handling, which has been changed to use a dedicated accept thread.
> Looking
> > > into this I have noticed a potential problem that is causing
> contention. I
> > > have submitted a fix at https://github.com/xnio/xnio/pull/94.
> > >
> > > Something else to note is that ab was 100% maxed out on a CPU core when
> > > running these tests. In general ab is not a great load driver as it is
> > > single threaded.
> > >
> > > The results get much more interesting if you modify the bench.sh
> slightly
> > > by adding an '&' to the end of the ab line and removing the 'sleep 5'
> call.
> > > This makes all 5 ab instances run at once, which is enough to max out
> the
> > > CPU on my machine (I also multiplied the number of requests by 5, the
> > > current number is a bit low).
> > >
> > > Using this approach I get the following results (3.3.6.Final-SNAPSHOT
> > > includes the PR I linked above):
> > >
> > > Non persistent connections:
> > >
> > > Beta9:                                    8,810
> > > 1.3.18.Final:                             6,578
> > > 1.3.18.Final + XNIO 3.3.6.Final-SNAPSHOT: 10,285
> > >
> > > When under heavy load the accept thread approach performs much better
> than
> > > the old approach (which was what we saw in Specj), however the XNIO
> bug was
> > > causing problems.
> > >
> > > Jim, because you saw a much greater performance loss that I did would
> you
> > > be able to re-run some of these tests with my XNIO changes and verify
> that
> > > this also fixes the issue for you (ideally using multiple ab instances
> to
> > > really load the machine)? If there are still problems I would like to
> know
> > > what sort of hardware you are seeing this on.
> > >
> > >
> > > Stuart
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Andrig T. Miller" <anmiller at redhat.com>
> > > > To: "Jim Crossley" <jim at crossleys.org>
> > > > Cc: "Stuart Douglas" <sdouglas at redhat.com>,
> undertow-dev at lists.jboss.org
> > > > Sent: Thursday, 10 March, 2016 8:28:37 AM
> > > > Subject: Re: [undertow-dev] Loss of perfomance between 1.3.0.Beta9
> and
> > >       1.3.18.Final
> > > >
> > > > Stuart,
> > > >
> > > > I'm not sure what this undertow-speed app does, but I'm nervous that
> > > tuning
> > > > for it, may undo some of the improvements we made in the performance
> lab.
> > > > One thing I would suggest though, is using perf on Linux and
> creating a
> > > > flamegraph for Beta9 and the Final. It's likely that some methods
> that
> > > were
> > > > being inlined are no longer being inlined, and the flamegraphs and
> the
> > > > underlying perf data will show that. In order to use perf you have
> to set
> > > > the JVM parameter to preserve frame pointers:
> > > >
> > > > -XX:+PreserveFramePointer
> > > >
> > > > Ping anyone from the performance team, and they can help you with the
> > > setup
> > > > of perf, and generating the flame graphs.
> > > >
> > > > Andy
> > > >
> > > > ----- Original Message -----
> > > >
> > > > > Hi Stuart,
> > > >
> > > > > Toby asked me to try on my machine, and I see an even bigger
> > > > > throughput disparity. I'm using his test app:
> > > > > https://github.com/tobias/undertow-speed
> > > >
> > > > > In one shell I run 'mvn clean compile exec:java' and in another I
> run
> > > > > './bench-avg.sh' and I get this output:
> > > >
> > > > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > > > Requests per second: 14717.03 [#/sec] (mean)
> > > > > Requests per second: 14527.32 [#/sec] (mean)
> > > > > Requests per second: 14288.32 [#/sec] (mean)
> > > > > Requests per second: 14375.64 [#/sec] (mean)
> > > > > Requests per second: 14653.08 [#/sec] (mean)
> > > > > Average: 14512
> > > >
> > > > > Then I run 'mvn clean compile exec:java -Pbeta9' in the first shell
> > > > > and re-run bench-avg.sh. I get this:
> > > >
> > > > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > > > Requests per second: 24069.72 [#/sec] (mean)
> > > > > Requests per second: 25002.35 [#/sec] (mean)
> > > > > Requests per second: 24885.36 [#/sec] (mean)
> > > > > Requests per second: 25261.30 [#/sec] (mean)
> > > > > Requests per second: 24800.82 [#/sec] (mean)
> > > > > Average: 24803.4
> > > >
> > > > > As you can see, quite a bit more than 7%, beta9 yields almost 70%
> > > > > better throughput for me!
> > > >
> > > > > I set the option you suggested for 1.3.18 and I get slightly better
> > > > > numbers:
> > > >
> > > > > jim at minty ~/apps/undertow-speed $ ./bench-avg.sh
> > > > > Requests per second: 15749.52 [#/sec] (mean)
> > > > > Requests per second: 15309.83 [#/sec] (mean)
> > > > > Requests per second: 15909.15 [#/sec] (mean)
> > > > > Requests per second: 16228.10 [#/sec] (mean)
> > > > > Requests per second: 16118.84 [#/sec] (mean)
> > > > > Average: 15862.6
> > > >
> > > > > But nowhere close to beta9.
> > > >
> > > > > Can you clone his app and reproduce locally?
> > > >
> > > > > Thanks,
> > > > > Jim
> > > >
> > > > > On Tue, Mar 8, 2016 at 6:35 PM, Stuart Douglas <
> sdouglas at redhat.com>
> > > wrote:
> > > > > > Can you re-run but with the following setting:
> > > > > >
> > > > > > .setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, -1)
> > > > > >
> > > > > > The default changed between these versions, so now idle
> connections
> > > will
> > > > > > eventually be timed out (otherwise browsers can hold connections
> for
> > > a
> > > > > > very time long which was causing people to have issues with FD
> > > > > > exhaustion).
> > > > > >
> > > > > > Stuart
> > > > > >
> > > > > > ----- Original Message -----
> > > > > >> From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > >> To: "Toby Crawley" <toby at tcrawley.org>
> > > > > >> Cc: undertow-dev at lists.jboss.org
> > > > > >> Sent: Monday, 7 March, 2016 10:59:27 AM
> > > > > >> Subject: Re: [undertow-dev] Loss of perfomance between
> 1.3.0.Beta9
> > > and
> > > > > >> 1.3.18.Final
> > > > > >>
> > > > > >> This is not a known issue, I will investigate.
> > > > > >>
> > > > > >> Stuart
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >> > From: "Toby Crawley" <toby at tcrawley.org>
> > > > > >> > To: undertow-dev at lists.jboss.org
> > > > > >> > Sent: Saturday, 5 March, 2016 7:29:00 AM
> > > > > >> > Subject: [undertow-dev] Loss of perfomance between
> 1.3.0.Beta9 and
> > > > > >> > 1.3.18.Final
> > > > > >> >
> > > > > >> > Is there a known decrease in throughput (measured with req/s)
> > > > > >> > between 1.3.0.Beta9 and 1.3.18.Final? We currently ship the
> former
> > > > > >> > with Immutant, and were looking at upgrading to the latter in
> the
> > > next
> > > > > >> > release, but noticed a decrease in throughput with a simple
> > > Clojure
> > > > > >> > benchmark app.
> > > > > >> >
> > > > > >> > I have replicated the basics of our benchmark app in Java[1],
> and
> > > saw
> > > > > >> > a
> > > > > >> > decrease in req/s between the two versions of ~7% when testing
> > > with ab
> > > > > >> > and averaging the output of several runs.
> > > > > >> >
> > > > > >> > Is there something that changed between those versions that is
> > > known
> > > > > >> > to have reduced performance?
> > > > > >> >
> > > > > >> > - Toby
> > > > > >> >
> > > > > >> > [1]: https://github.com/tobias/undertow-speed
> > > > > >> > _______________________________________________
> > > > > >> > 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
> > > > > _______________________________________________
> > > > > 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/20160310/3149e3b6/attachment.html 

From robin.anil at gmail.com  Tue Mar 22 11:52:43 2016
From: robin.anil at gmail.com (Robin Anil)
Date: Tue, 22 Mar 2016 15:52:43 +0000
Subject: [undertow-dev] We are noticing broken websocket messages
Message-ID: <CAB+3LJkF08J7bxxODSiY-JFBqt+rGpX9Y0f_L96BNLrw30GQNg@mail.gmail.com>

Stuart,

We are using undertow websocket library for passing back and forth
serialized JSON messages using Websockets.sendText method

On the client side in Chrome we are noticing that that instead of 1 message
we are receiving 2 where the first one is truncated at some 323,821 B and
the second message is of 148,583 but malformed (its text but its garbled)
and therefore not a JSON even if its concatenated with the first message

We are converting protocol buffers to JSON on the server side and can't
point the finger at that code as it had worked for even bigger JSON
messages.

To investigate this further I need help ruling out any message size or
frame size limitation on undertow that could cause this. Any pointers here
would be helpful.

Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160322/45ac2e66/attachment-0001.html 

From sdouglas at redhat.com  Tue Mar 22 18:30:34 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 23 Mar 2016 09:30:34 +1100
Subject: [undertow-dev] We are noticing broken websocket messages
In-Reply-To: <CAB+3LJkF08J7bxxODSiY-JFBqt+rGpX9Y0f_L96BNLrw30GQNg@mail.gmail.com>
References: <CAB+3LJkF08J7bxxODSiY-JFBqt+rGpX9Y0f_L96BNLrw30GQNg@mail.gmail.com>
Message-ID: <CAD+L2czVZfa+c7+zmCVdUtazcLcKfR=X=zCMdmXC_XLLvtr5gQ@mail.gmail.com>

Their is no internal limitation in Undertow. Do you have a simple
reproducer I can look at?

Stuart

On Wed, Mar 23, 2016 at 2:52 AM, Robin Anil <robin.anil at gmail.com> wrote:
> Stuart,
>
> We are using undertow websocket library for passing back and forth
> serialized JSON messages using Websockets.sendText method
>
> On the client side in Chrome we are noticing that that instead of 1 message
> we are receiving 2 where the first one is truncated at some 323,821 B and
> the second message is of 148,583 but malformed (its text but its garbled)
> and therefore not a JSON even if its concatenated with the first message
>
> We are converting protocol buffers to JSON on the server side and can't
> point the finger at that code as it had worked for even bigger JSON
> messages.
>
> To investigate this further I need help ruling out any message size or frame
> size limitation on undertow that could cause this. Any pointers here would
> be helpful.
>
> Robin

From golovnin at gmx.net  Wed Mar 23 16:33:51 2016
From: golovnin at gmx.net (Andrej Golovnin)
Date: Wed, 23 Mar 2016 21:33:51 +0100
Subject: [undertow-dev] Broken #toArray-methods in
	SecureHashMap$KeySet/Values/EntrySet
Message-ID: <A0A2FD86-4D2E-4222-9806-F651847F8A33@gmx.net>

Hi Stuart,

all toArray-methods implementations in the classes

SecureHashMap$KeySet
SecureHashMap$Values
SecureHashMap$EntrySet

are broken and throw StackOverflowError.
The methods can be removed from this classes because
the parent class AbstractCollection provides valid
implementations of this methods.

The class SecureHashMap is not used in Undertow and 
I think it is not used in WildFly too. Therefore maybe
it makes sense to remove the whole class SecureHashMap.

Best regards,
Andrej Golovnin

From mike at stardog.com  Thu Mar 31 06:58:25 2016
From: mike at stardog.com (Michael Grove)
Date: Thu, 31 Mar 2016 06:58:25 -0400
Subject: [undertow-dev] how to use ExceptionHandler & security together
Message-ID: <CAKqS+r04zDgkHXbMDhdRxDRYHt-6cLeaQZT8aTjp651a5AtF+g@mail.gmail.com>

I have a pretty basic server set up:

ExceptionHandler -> Security Handlers * -> PathTemplateHandler -> my routes

* The security handlers are set up as shown in the examples [1] and I'm
also using the same `IdentityManager` for my tinkering.

What I'm seeing is that in ExceptionHandler [2] the request is just passed
directly onto the next handler, which in this case, is the start of the
security handlers.

The request is passed through each handler until it hits
`AuthenticationCallHandler` and is moved off the IO thread [3]. The call
then returns, and all the invocations to the next handler finish back up
the stack until `ExceptionHandler`, where the call completes successfully.

Trouble is, the request was malformed and the route handling it threw an
exception and it wasn't handled as expected.

I guess the correct answer is that I shouldn't have allowed it to get
thrown out of the handler for the route; catch it there and send the
expected error response.

But, I'm curious if there was a way to do this with the handlers, or
perhaps, more generally, what are the expectations along the call chain of
handlers when some may move off the initial IO thread.

Thanks.

Mike


[1]
https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/security/basic/BasicAuthServer.java
[2]
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/ExceptionHandler.java#L29
[3]
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/handlers/AuthenticationCallHandler.java#L45-L48
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160331/746e95eb/attachment.html