From sdouglas at redhat.com  Fri Apr  1 01:15:01 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 1 Apr 2016 16:15:01 +1100
Subject: [undertow-dev] how to use ExceptionHandler & security together
In-Reply-To: <CAKqS+r04zDgkHXbMDhdRxDRYHt-6cLeaQZT8aTjp651a5AtF+g@mail.gmail.com>
References: <CAKqS+r04zDgkHXbMDhdRxDRYHt-6cLeaQZT8aTjp651a5AtF+g@mail.gmail.com>
Message-ID: <CAD+L2cwjkhYPDFyFV2hx9D3AA2aLOGEAzZnszdkuRb8bcuGLAA@mail.gmail.com>

The simplest way to make this work would be to do the dispatch to a
worker thread before the ExceptionHandler, the security handlers won't
dispatch again if it has already been dispatched.

Stuart

On Thu, Mar 31, 2016 at 9:58 PM, Michael Grove <mike at stardog.com> wrote:
> 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
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From mail at christianbauer.name  Tue Apr  5 08:37:49 2016
From: mail at christianbauer.name (Christian Bauer)
Date: Tue, 5 Apr 2016 14:37:49 +0200
Subject: [undertow-dev] Classpath conflict with Tyrus client
Message-ID: <F236F716-F609-468A-BB04-B1E089743C87@christianbauer.name>

Hi

I'm creating and testing websockets in my project and I have the following classpath:

    compile "io.undertow:undertow-servlet:$undertowVersion"
    compile "io.undertow:undertow-websockets-jsr:$undertowVersion"
    testCompile "org.glassfish.tyrus:tyrus-client:$tyrusVersion"
    testCompile "org.glassfish.tyrus:tyrus-container-grizzly-client:$tyrusVersion"

This doesn't work:

Caused by: java.lang.ClassCastException: org.glassfish.tyrus.client.ClientManager cannot be cast to io.undertow.websockets.jsr.ServerWebSocketContainer
	at io.undertow.websockets.jsr.Bootstrap.handleDeployment(Bootstrap.java:62)
	at io.undertow.servlet.core.DeploymentManagerImpl.handleExtensions(DeploymentManagerImpl.java:252)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:152)

The code in Bootstrap.java randomly picks an implementation through ServiceLoader and tries to cast it:

https://github.com/undertow-io/undertow/blob/master/websockets-jsr/src/main/java/io/undertow/websockets/jsr/Bootstrap.java#L62

Why not load the desired type directly? Should I be able to deploy several websocket implementations? If not, what's the best option for testing?

Thanks,
Christian



From sdouglas at redhat.com  Tue Apr  5 18:19:53 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 6 Apr 2016 08:19:53 +1000
Subject: [undertow-dev] Classpath conflict with Tyrus client
In-Reply-To: <F236F716-F609-468A-BB04-B1E089743C87@christianbauer.name>
References: <F236F716-F609-468A-BB04-B1E089743C87@christianbauer.name>
Message-ID: <CAD+L2cxPnfjXDwDezaCptGOCQQC3KHaJw7m_a2nQFzwZ0vXzNQ@mail.gmail.com>

I will change this, but you should be able to work around it by
setting the worker and buffers on your WebSocketDeploymentInfo.


Stuart

On Tue, Apr 5, 2016 at 10:37 PM, Christian Bauer
<mail at christianbauer.name> wrote:
> Hi
>
> I'm creating and testing websockets in my project and I have the following classpath:
>
>     compile "io.undertow:undertow-servlet:$undertowVersion"
>     compile "io.undertow:undertow-websockets-jsr:$undertowVersion"
>     testCompile "org.glassfish.tyrus:tyrus-client:$tyrusVersion"
>     testCompile "org.glassfish.tyrus:tyrus-container-grizzly-client:$tyrusVersion"
>
> This doesn't work:
>
> Caused by: java.lang.ClassCastException: org.glassfish.tyrus.client.ClientManager cannot be cast to io.undertow.websockets.jsr.ServerWebSocketContainer
>         at io.undertow.websockets.jsr.Bootstrap.handleDeployment(Bootstrap.java:62)
>         at io.undertow.servlet.core.DeploymentManagerImpl.handleExtensions(DeploymentManagerImpl.java:252)
>         at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:152)
>
> The code in Bootstrap.java randomly picks an implementation through ServiceLoader and tries to cast it:
>
> https://github.com/undertow-io/undertow/blob/master/websockets-jsr/src/main/java/io/undertow/websockets/jsr/Bootstrap.java#L62
>
> Why not load the desired type directly? Should I be able to deploy several websocket implementations? If not, what's the best option for testing?
>
> Thanks,
> Christian
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From robin.anil at gmail.com  Wed Apr  6 13:33:49 2016
From: robin.anil at gmail.com (Robin Anil)
Date: Wed, 06 Apr 2016 17:33:49 +0000
Subject: [undertow-dev] We are noticing broken websocket messages
In-Reply-To: <CAD+L2czVZfa+c7+zmCVdUtazcLcKfR=X=zCMdmXC_XLLvtr5gQ@mail.gmail.com>
References: <CAB+3LJkF08J7bxxODSiY-JFBqt+rGpX9Y0f_L96BNLrw30GQNg@mail.gmail.com>
	<CAD+L2czVZfa+c7+zmCVdUtazcLcKfR=X=zCMdmXC_XLLvtr5gQ@mail.gmail.com>
Message-ID: <CAB+3LJk=fnOdZ1S2WuAiTHZCPL_9GAZN7jvjy8d3otrTkxftOA@mail.gmail.com>

Sorry for not getting back because I didn't have a repro case. This issue
happened last night and I was noticing that it was because the per-message
size was in the 300K to 500K range.

So I tried to reduce our payload our issue went away. Digging in I noticed
that the moment I disable  PerMessageDeflateHandshake() extension the error
goes away even at the large batch size. So this is what I have as an repro
so far


Robin

On Tue, Mar 22, 2016 at 5:30 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160406/9b3d35e4/attachment-0001.html 

From sdouglas at redhat.com  Wed Apr  6 17:57:15 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 7 Apr 2016 07:57:15 +1000
Subject: [undertow-dev] We are noticing broken websocket messages
In-Reply-To: <CAB+3LJk=fnOdZ1S2WuAiTHZCPL_9GAZN7jvjy8d3otrTkxftOA@mail.gmail.com>
References: <CAB+3LJkF08J7bxxODSiY-JFBqt+rGpX9Y0f_L96BNLrw30GQNg@mail.gmail.com>
	<CAD+L2czVZfa+c7+zmCVdUtazcLcKfR=X=zCMdmXC_XLLvtr5gQ@mail.gmail.com>
	<CAB+3LJk=fnOdZ1S2WuAiTHZCPL_9GAZN7jvjy8d3otrTkxftOA@mail.gmail.com>
Message-ID: <CAD+L2czJHFzDV+xT2OOpR6Ww3VxGC32BXmw8LRpuk+1-tQK15w@mail.gmail.com>

Sounds like a bug in the extension, can you file a JIRA about this?

Stuart

On Thu, Apr 7, 2016 at 3:33 AM, Robin Anil <robin.anil at gmail.com> wrote:
> Sorry for not getting back because I didn't have a repro case. This issue
> happened last night and I was noticing that it was because the per-message
> size was in the 300K to 500K range.
>
> So I tried to reduce our payload our issue went away. Digging in I noticed
> that the moment I disable  PerMessageDeflateHandshake() extension the error
> goes away even at the large batch size. So this is what I have as an repro
> so far
>
>
> Robin
>
> On Tue, Mar 22, 2016 at 5:30 PM Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> 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 robin.anil at gmail.com  Thu Apr  7 11:23:29 2016
From: robin.anil at gmail.com (Robin Anil)
Date: Thu, 07 Apr 2016 15:23:29 +0000
Subject: [undertow-dev] We are noticing broken websocket messages
In-Reply-To: <CAD+L2czJHFzDV+xT2OOpR6Ww3VxGC32BXmw8LRpuk+1-tQK15w@mail.gmail.com>
References: <CAB+3LJkF08J7bxxODSiY-JFBqt+rGpX9Y0f_L96BNLrw30GQNg@mail.gmail.com>
	<CAD+L2czVZfa+c7+zmCVdUtazcLcKfR=X=zCMdmXC_XLLvtr5gQ@mail.gmail.com>
	<CAB+3LJk=fnOdZ1S2WuAiTHZCPL_9GAZN7jvjy8d3otrTkxftOA@mail.gmail.com>
	<CAD+L2czJHFzDV+xT2OOpR6Ww3VxGC32BXmw8LRpuk+1-tQK15w@mail.gmail.com>
Message-ID: <CAB+3LJmawpiDqi5nv0O9dv=B+x9Mxoh=ftktLWsV59x1mK2Heg@mail.gmail.com>

Filed https://issues.jboss.org/browse/UNDERTOW-684

On Wed, Apr 6, 2016 at 4:57 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> Sounds like a bug in the extension, can you file a JIRA about this?
>
> Stuart
>
> On Thu, Apr 7, 2016 at 3:33 AM, Robin Anil <robin.anil at gmail.com> wrote:
> > Sorry for not getting back because I didn't have a repro case. This issue
> > happened last night and I was noticing that it was because the
> per-message
> > size was in the 300K to 500K range.
> >
> > So I tried to reduce our payload our issue went away. Digging in I
> noticed
> > that the moment I disable  PerMessageDeflateHandshake() extension the
> error
> > goes away even at the large batch size. So this is what I have as an
> repro
> > so far
> >
> >
> > Robin
> >
> > On Tue, Mar 22, 2016 at 5:30 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160407/00b8080e/attachment.html 

From miere.teixeira at gmail.com  Thu Apr  7 14:52:30 2016
From: miere.teixeira at gmail.com (Miere Teixeira)
Date: Thu, 07 Apr 2016 18:52:30 +0000
Subject: [undertow-dev] Improving Undertow performance
Message-ID: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>

Hi Stuart,

I've followed undertow benchmark on Techempower's Benchmark page
<https://www.techempower.com/benchmarks/> almost 2 years and I've noticed
that undertow's benchmark code
<https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Java/undertow>
has not been updated since last year.

I'd like to know what are your tips to improve Undertow's performance on TE
Benchmark.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160407/ada01406/attachment.html 

From anmiller at redhat.com  Thu Apr  7 16:11:32 2016
From: anmiller at redhat.com (Andrig T. Miller)
Date: Thu, 7 Apr 2016 16:11:32 -0400 (EDT)
Subject: [undertow-dev] Improving Undertow performance
In-Reply-To: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
References: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
Message-ID: <584632049.48896031.1460059892510.JavaMail.zimbra@redhat.com>

No to hijack the thread, but I don't think the techempower benchmark is worth much, in terms of knowing how Undertow will perform on a real workload. 

My 2 cents. 

Andy 

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

> Hi Stuart,

> I've followed undertow benchmark on Techempower's Benchmark page almost 2
> years and I've noticed that undertow's benchmark code has not been updated
> since last year.

> I'd like to know what are your tips to improve Undertow's performance on TE
> Benchmark.

> Regards

> _______________________________________________
> 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/20160407/c345a200/attachment.html 

From sdouglas at redhat.com  Thu Apr  7 17:11:22 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 8 Apr 2016 07:11:22 +1000
Subject: [undertow-dev] Improving Undertow performance
In-Reply-To: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
References: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
Message-ID: <CAD+L2cwj+ucF0naKBJx_19w7dg_y4EVarFuxu1f0sNP9Afz-eg@mail.gmail.com>

There is not really any low hanging fruit that I am aware of to make
that particular benchmark run faster.

One of the easiest ways to get it to run faster would be to strip out
all the Undertow code that is not relevant to the benchmark, however
that would not be particularly useful in the real world :-)

I do have a few ideas about what may help (the biggest one being lazy
allocation of headers to reduce allocations even further), however
this may not be possible without some API modifications, is a fair bit
of work, and may not actually help.

Feel free to profile it and if you can make some improvements that is
great, but I don't think there are any easy improvements any more.

Stuart

On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira at gmail.com> wrote:
> Hi Stuart,
>
> I've followed undertow benchmark on Techempower's Benchmark page almost 2
> years and I've noticed that undertow's benchmark code has not been updated
> since last year.
>
> I'd like to know what are your tips to improve Undertow's performance on TE
> Benchmark.
>
> Regards
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Thu Apr  7 20:05:37 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 8 Apr 2016 10:05:37 +1000
Subject: [undertow-dev] Improving Undertow performance
In-Reply-To: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
References: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
Message-ID: <CAD+L2cxj40+UMFG38A-VZzZJHf47PPoj1ysCZL=562Bf9riY4g@mail.gmail.com>

Something else to keep in mind is that you can't really compare
Undertow to rapidoid directly. The rapidoid benchmark is operating at
a much lower level than Undertow does (if you look at the code you
will see that they are basically manually writing headers and content
to the output buffer). This is great for writing really fast
benchmarks, but sucks in the real world.

Just on the output side Undertow has to do a lot more work, just off
the top of my head:

- Creating a data structure to hold the headers (when you are handling
millions of req/sec every allocation has a measurable cost)
- Iterating the above data structure to build a response
- Handling all the special case that go with the above, such as when
the headers are two big to fit in one buffer

All this is highly optimized, but it is obviously slower than simply
not having to do it.

Stuart


On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira at gmail.com> wrote:
> Hi Stuart,
>
> I've followed undertow benchmark on Techempower's Benchmark page almost 2
> years and I've noticed that undertow's benchmark code has not been updated
> since last year.
>
> I'd like to know what are your tips to improve Undertow's performance on TE
> Benchmark.
>
> Regards
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From greg.hellings at gmail.com  Thu Apr  7 20:15:09 2016
From: greg.hellings at gmail.com (Greg Hellings)
Date: Thu, 7 Apr 2016 19:15:09 -0500
Subject: [undertow-dev] Improving Undertow performance
In-Reply-To: <CAD+L2cxj40+UMFG38A-VZzZJHf47PPoj1ysCZL=562Bf9riY4g@mail.gmail.com>
References: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
	<CAD+L2cxj40+UMFG38A-VZzZJHf47PPoj1ysCZL=562Bf9riY4g@mail.gmail.com>
Message-ID: <CAHxvOVJrxk_YKqq4qHRGQLxGA=z7To1uxYPD9eYqve6Z_1L5Gg@mail.gmail.com>

To be fair, that's exactly what the TE benchmarks are supposed to
show. The relative overheads of each framework/solution combination.

So if it show that Undertow is slower than solutions that are not
frameworks, then it's showing exactly what it is supposed it!

It is up to the reader to look at those results and understand the
merits of a full, heavy framework (like Play) or a minimal solution
(like Undertow) or a raw solution (like rapidoid) for their project
velocity.

--Greg

On Thu, Apr 7, 2016 at 7:05 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> Something else to keep in mind is that you can't really compare
> Undertow to rapidoid directly. The rapidoid benchmark is operating at
> a much lower level than Undertow does (if you look at the code you
> will see that they are basically manually writing headers and content
> to the output buffer). This is great for writing really fast
> benchmarks, but sucks in the real world.
>
> Just on the output side Undertow has to do a lot more work, just off
> the top of my head:
>
> - Creating a data structure to hold the headers (when you are handling
> millions of req/sec every allocation has a measurable cost)
> - Iterating the above data structure to build a response
> - Handling all the special case that go with the above, such as when
> the headers are two big to fit in one buffer
>
> All this is highly optimized, but it is obviously slower than simply
> not having to do it.
>
> Stuart
>
>
> On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira at gmail.com> wrote:
>> Hi Stuart,
>>
>> I've followed undertow benchmark on Techempower's Benchmark page almost 2
>> years and I've noticed that undertow's benchmark code has not been updated
>> since last year.
>>
>> I'd like to know what are your tips to improve Undertow's performance on TE
>> Benchmark.
>>
>> Regards
>>
>>
>> _______________________________________________
>> 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 michael.hixson at gmail.com  Thu Apr  7 21:50:47 2016
From: michael.hixson at gmail.com (Michael Hixson)
Date: Thu, 7 Apr 2016 18:50:47 -0700
Subject: [undertow-dev] Improving Undertow performance
In-Reply-To: <CAHxvOVJrxk_YKqq4qHRGQLxGA=z7To1uxYPD9eYqve6Z_1L5Gg@mail.gmail.com>
References: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
	<CAD+L2cxj40+UMFG38A-VZzZJHf47PPoj1ysCZL=562Bf9riY4g@mail.gmail.com>
	<CAHxvOVJrxk_YKqq4qHRGQLxGA=z7To1uxYPD9eYqve6Z_1L5Gg@mail.gmail.com>
Message-ID: <CAHqckpNjP4VpyyABbDTN=N0w23wt7yA9-r34hzXvfmjxnBU4OA@mail.gmail.com>

As far as updates to the benchmark code itself, it should probably be
upgraded to the latest version of Undertow, but I don't see any
optimizations to make in the handler classes etc.

Trying the rapidoid approach with that code would be a mistake, in my
opinion.  Right now the undertow implementation is understandable and
high-level enough that someone could look at it and say "Yeah, I could
write a real application like that."  And it's still sitting near the
top of the charts.

Related -- some ASP.net devs talking about the benchmark and undertow
specifically as inspiration for their own performance improvements:
https://youtu.be/7O81CAjmOXk?t=16m40s

-Michael

On Thu, Apr 7, 2016 at 5:15 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
> To be fair, that's exactly what the TE benchmarks are supposed to
> show. The relative overheads of each framework/solution combination.
>
> So if it show that Undertow is slower than solutions that are not
> frameworks, then it's showing exactly what it is supposed it!
>
> It is up to the reader to look at those results and understand the
> merits of a full, heavy framework (like Play) or a minimal solution
> (like Undertow) or a raw solution (like rapidoid) for their project
> velocity.
>
> --Greg
>
> On Thu, Apr 7, 2016 at 7:05 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
>> Something else to keep in mind is that you can't really compare
>> Undertow to rapidoid directly. The rapidoid benchmark is operating at
>> a much lower level than Undertow does (if you look at the code you
>> will see that they are basically manually writing headers and content
>> to the output buffer). This is great for writing really fast
>> benchmarks, but sucks in the real world.
>>
>> Just on the output side Undertow has to do a lot more work, just off
>> the top of my head:
>>
>> - Creating a data structure to hold the headers (when you are handling
>> millions of req/sec every allocation has a measurable cost)
>> - Iterating the above data structure to build a response
>> - Handling all the special case that go with the above, such as when
>> the headers are two big to fit in one buffer
>>
>> All this is highly optimized, but it is obviously slower than simply
>> not having to do it.
>>
>> Stuart
>>
>>
>> On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira at gmail.com> wrote:
>>> Hi Stuart,
>>>
>>> I've followed undertow benchmark on Techempower's Benchmark page almost 2
>>> years and I've noticed that undertow's benchmark code has not been updated
>>> since last year.
>>>
>>> I'd like to know what are your tips to improve Undertow's performance on TE
>>> Benchmark.
>>>
>>> Regards
>>>
>>>
>>> _______________________________________________
>>> 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 jason.greene at redhat.com  Fri Apr  8 00:13:08 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 8 Apr 2016 00:13:08 -0400 (EDT)
Subject: [undertow-dev] Improving Undertow performance
In-Reply-To: <CAHqckpNjP4VpyyABbDTN=N0w23wt7yA9-r34hzXvfmjxnBU4OA@mail.gmail.com>
References: <CAHezjrSzumw2QnPSC5yfE_02BEivNkRPqk4Wrjp3WSWRzdrozQ@mail.gmail.com>
	<CAD+L2cxj40+UMFG38A-VZzZJHf47PPoj1ysCZL=562Bf9riY4g@mail.gmail.com>
	<CAHxvOVJrxk_YKqq4qHRGQLxGA=z7To1uxYPD9eYqve6Z_1L5Gg@mail.gmail.com>
	<CAHqckpNjP4VpyyABbDTN=N0w23wt7yA9-r34hzXvfmjxnBU4OA@mail.gmail.com>
Message-ID: <C260E822-5DE3-4D89-8B7A-3687A02EAC39@redhat.com>

Cool. Thanks for the forward!

> On Apr 7, 2016, at 8:51 PM, Michael Hixson <michael.hixson at gmail.com> wrote:
> 
> As far as updates to the benchmark code itself, it should probably be
> upgraded to the latest version of Undertow, but I don't see any
> optimizations to make in the handler classes etc.
> 
> Trying the rapidoid approach with that code would be a mistake, in my
> opinion.  Right now the undertow implementation is understandable and
> high-level enough that someone could look at it and say "Yeah, I could
> write a real application like that."  And it's still sitting near the
> top of the charts.
> 
> Related -- some ASP.net devs talking about the benchmark and undertow
> specifically as inspiration for their own performance improvements:
> https://youtu.be/7O81CAjmOXk?t=16m40s
> 
> -Michael
> 
>> On Thu, Apr 7, 2016 at 5:15 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
>> To be fair, that's exactly what the TE benchmarks are supposed to
>> show. The relative overheads of each framework/solution combination.
>> 
>> So if it show that Undertow is slower than solutions that are not
>> frameworks, then it's showing exactly what it is supposed it!
>> 
>> It is up to the reader to look at those results and understand the
>> merits of a full, heavy framework (like Play) or a minimal solution
>> (like Undertow) or a raw solution (like rapidoid) for their project
>> velocity.
>> 
>> --Greg
>> 
>>> On Thu, Apr 7, 2016 at 7:05 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>> Something else to keep in mind is that you can't really compare
>>> Undertow to rapidoid directly. The rapidoid benchmark is operating at
>>> a much lower level than Undertow does (if you look at the code you
>>> will see that they are basically manually writing headers and content
>>> to the output buffer). This is great for writing really fast
>>> benchmarks, but sucks in the real world.
>>> 
>>> Just on the output side Undertow has to do a lot more work, just off
>>> the top of my head:
>>> 
>>> - Creating a data structure to hold the headers (when you are handling
>>> millions of req/sec every allocation has a measurable cost)
>>> - Iterating the above data structure to build a response
>>> - Handling all the special case that go with the above, such as when
>>> the headers are two big to fit in one buffer
>>> 
>>> All this is highly optimized, but it is obviously slower than simply
>>> not having to do it.
>>> 
>>> Stuart
>>> 
>>> 
>>>> On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira at gmail.com> wrote:
>>>> Hi Stuart,
>>>> 
>>>> I've followed undertow benchmark on Techempower's Benchmark page almost 2
>>>> years and I've noticed that undertow's benchmark code has not been updated
>>>> since last year.
>>>> 
>>>> I'd like to know what are your tips to improve Undertow's performance on TE
>>>> Benchmark.
>>>> 
>>>> Regards
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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 tobias.verbeke at openanalytics.eu  Thu Apr 21 16:40:49 2016
From: tobias.verbeke at openanalytics.eu (Tobias Verbeke)
Date: Thu, 21 Apr 2016 22:40:49 +0200 (CEST)
Subject: [undertow-dev] WebSocket Proxying
Message-ID: <1486843826.90349.1461271249676.JavaMail.zimbra@openanalytics.eu>

Hello, 

I discovered undertow earlier today and its intro page mentions 'Web Sockets' and 'Reverse Proxy' as features.

According to Google and SO there is currently no Java technology that can do Web Socket proxying.

One such post is the following:

http://stackoverflow.com/questions/22262468/jetty-websocket-proxying

Do you think undertow would be up to the task? Has anyone relevant experience?

Many thanks in advance for any pointer.

Best,
Tobias

From sdouglas at redhat.com  Thu Apr 21 18:55:31 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 22 Apr 2016 08:55:31 +1000
Subject: [undertow-dev] WebSocket Proxying
In-Reply-To: <1486843826.90349.1461271249676.JavaMail.zimbra@openanalytics.eu>
References: <1486843826.90349.1461271249676.JavaMail.zimbra@openanalytics.eu>
Message-ID: <CAD+L2cxmtLSdw9bmsMPBjmjdNGip5tEZatuYcvrcTDn0RCK9Cw@mail.gmail.com>

Undertow can indeed handle this. Basically after the upgrade the
reverse proxy just forwards data to the selected backend server, and
forwards data back to the client (the proxy does not parse the
websocket protocol, as it does not need to).

The easiest way to see this in action is probably by combining our
reverse proxy and websocket examples. If you run the testsuite with
-Pproxy it will run all the tests (including websocket tests) through
a reverse proxy.

Stuart





On Fri, Apr 22, 2016 at 6:40 AM, Tobias Verbeke
<tobias.verbeke at openanalytics.eu> wrote:
> Hello,
>
> I discovered undertow earlier today and its intro page mentions 'Web Sockets' and 'Reverse Proxy' as features.
>
> According to Google and SO there is currently no Java technology that can do Web Socket proxying.
>
> One such post is the following:
>
> http://stackoverflow.com/questions/22262468/jetty-websocket-proxying
>
> Do you think undertow would be up to the task? Has anyone relevant experience?
>
> Many thanks in advance for any pointer.
>
> Best,
> Tobias
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From tobias.verbeke at openanalytics.eu  Fri Apr 22 17:09:51 2016
From: tobias.verbeke at openanalytics.eu (Tobias Verbeke)
Date: Fri, 22 Apr 2016 23:09:51 +0200 (CEST)
Subject: [undertow-dev] WebSocket Proxying
In-Reply-To: <CAD+L2cxmtLSdw9bmsMPBjmjdNGip5tEZatuYcvrcTDn0RCK9Cw@mail.gmail.com>
References: <1486843826.90349.1461271249676.JavaMail.zimbra@openanalytics.eu>
	<CAD+L2cxmtLSdw9bmsMPBjmjdNGip5tEZatuYcvrcTDn0RCK9Cw@mail.gmail.com>
Message-ID: <1841696409.164732.1461359391096.JavaMail.zimbra@openanalytics.eu>

Hi Stuart,

Many thanks for your reply and for pointing me in the right direction. This is wonderful news!

Best,
Tobias

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Tobias Verbeke" <tobias.verbeke at openanalytics.eu>
> Cc: "Undertow Developers" <undertow-dev at lists.jboss.org>
> Sent: Friday, April 22, 2016 12:55:31 AM
> Subject: Re: [undertow-dev] WebSocket Proxying

> Undertow can indeed handle this. Basically after the upgrade the
> reverse proxy just forwards data to the selected backend server, and
> forwards data back to the client (the proxy does not parse the
> websocket protocol, as it does not need to).
> 
> The easiest way to see this in action is probably by combining our
> reverse proxy and websocket examples. If you run the testsuite with
> -Pproxy it will run all the tests (including websocket tests) through
> a reverse proxy.
> 
> Stuart
> 
> 
> 
> 
> 
> On Fri, Apr 22, 2016 at 6:40 AM, Tobias Verbeke
> <tobias.verbeke at openanalytics.eu> wrote:
>> Hello,
>>
>> I discovered undertow earlier today and its intro page mentions 'Web Sockets'
>> and 'Reverse Proxy' as features.
>>
>> According to Google and SO there is currently no Java technology that can do Web
>> Socket proxying.
>>
>> One such post is the following:
>>
>> http://stackoverflow.com/questions/22262468/jetty-websocket-proxying
>>
>> Do you think undertow would be up to the task? Has anyone relevant experience?
>>
>> Many thanks in advance for any pointer.
>>
>> Best,
>> Tobias
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev