From ping.li at firemon.com  Fri Jul  1 14:02:15 2016
From: ping.li at firemon.com (PingShan Li)
Date: Fri, 1 Jul 2016 18:02:15 +0000
Subject: [undertow-dev] permessage-deflate extension is not supported,
 getInstalledExtensions() returns empty set in
 ServerWebSocketContainer.java
In-Reply-To: <CAD+L2cwukkqWtjWEDAm_o7+9U+OznNsCiCYZUSig654e5VB2Dg@mail.gmail.com>
References: <CY1PR10MB03140FBB3D67F9F1F2FE9398FA230@CY1PR10MB0314.namprd10.prod.outlook.com>,
	<CAD+L2cwukkqWtjWEDAm_o7+9U+OznNsCiCYZUSig654e5VB2Dg@mail.gmail.com>
Message-ID: <CY1PR10MB031490544492486E47D2694DFA250@CY1PR10MB0314.namprd10.prod.outlook.com>

Based on your suggestion, we are able to add extension PerMessageDeflateHandshake to WebSocketDeploymentInfo.

In the constructor of the ServerWebSocketContainer, the installedExtensions has one element of PerMessageDeflateHandshake. But when the getInstalledExtensions is called, it still returns empty set, should that function return installedExtensions instead of Collections.emptySet()?

    public ServerWebSocketContainer(final ClassIntrospecter classIntrospecter, final ClassLoader classLoader, XnioWorker xnioWorker, ByteBufferPool bufferPool, ThreadSetupAction threadSetupAction, boolean dispatchToWorker, InetSocketAddress clientBindAddress, WebSocketReconnectHandler reconnectHandler, List<Extension> installedExtensions) {
        this.classIntrospecter = classIntrospecter;
        this.bufferPool = bufferPool;
        this.xnioWorker = xnioWorker;
        this.threadSetupAction = threadSetupAction;
        this.dispatchToWorker = dispatchToWorker;
        this.clientBindAddress = clientBindAddress;
        this.installedExtensions = new ArrayList<>(installedExtensions);
        List<WebsocketClientSslProvider> clientSslProviders = new ArrayList<>();
        for (WebsocketClientSslProvider provider : ServiceLoader.load(WebsocketClientSslProvider.class, classLoader)) {
            clientSslProviders.add(provider);
        }

        this.clientSslProviders = Collections.unmodifiableList(clientSslProviders);
        this.webSocketReconnectHandler = reconnectHandler;
    }

    public Set<Extension> getInstalledExtensions() {
        return Collections.emptySet();
    }



________________________________
From: Stuart Douglas <sdouglas at redhat.com>
Sent: Wednesday, June 29, 2016 7:00:31 PM
To: PingShan Li
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] permessage-deflate extension is not supported, getInstalledExtensions() returns empty set in ServerWebSocketContainer.java

You need to invoke
io.undertow.websockets.jsr.WebSocketDeploymentInfo#addExtension with
an instance of io.undertow.websockets.extensions.PerMessageDeflateHandshake


Stuart

On Thu, Jun 30, 2016 at 6:16 AM, PingShan Li <ping.li at firemon.com> wrote:
> --- Problem:
> client's request for compression is ignored.
>
> The client sends the request for compression:
>
> Sec-WebSocket-Extensions: permessage-deflate; client_no_context_takeover;
> client_max_window_bits\r\n
>
>
> Webserver receives the client request,
>
>
> org.springframework.web.socket.server.support.AbstractHandshakeHandler.java:
>
> doHandshake function: try to see if requested extension is supported
>
> String subProtocol = selectProtocol(headers.getSecWebSocketProtocol(),
> wsHandler);
> List<WebSocketExtension> requested = headers.getSecWebSocketExtensions();
> List<WebSocketExtension> supported =
> this.requestUpgradeStrategy.getSupportedExtensions(request);
> List<WebSocketExtension> extensions = filterRequestedExtensions(request,
> requested, supported);
>
> getSupportedExtensions calls into the following function, which always
> returns empty set for installed extensions.
>
> io.undertow.websockets.jsr.ServerWebSocketContainer.java:
>
>     public Set<Extension> getInstalledExtensions() {
>         return Collections.emptySet();
>     }
>
> My question is:
> how to tell spring framework that the permessage-deflate extension is
> supported by undertow?
>
> Environement:
> Undertow 1.3.22 Final is used by springframework:
> +-
> org.springframework.boot:spring-boot-starter-undertow:jar:1.3.5.RELEASE:compile
> [INFO] |  |  +- io.undertow:undertow-core:jar:1.3.22.Final:compile
> [INFO] |  |  +- io.undertow:undertow-servlet:jar:1.3.22.Final:compile
> [INFO] |  |  +- io.undertow:undertow-websockets-jsr:jar:1.3.22.Final:compile
>
>
> Thanks
>
>
>
>
>
>
> _______________________________________________
> 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/20160701/01f7c442/attachment.html 

From sdouglas at redhat.com  Sat Jul  2 19:50:59 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 3 Jul 2016 09:50:59 +1000
Subject: [undertow-dev] permessage-deflate extension is not supported,
 getInstalledExtensions() returns empty set in
 ServerWebSocketContainer.java
In-Reply-To: <CY1PR10MB031490544492486E47D2694DFA250@CY1PR10MB0314.namprd10.prod.outlook.com>
References: <CY1PR10MB03140FBB3D67F9F1F2FE9398FA230@CY1PR10MB0314.namprd10.prod.outlook.com>
	<CAD+L2cwukkqWtjWEDAm_o7+9U+OznNsCiCYZUSig654e5VB2Dg@mail.gmail.com>
	<CY1PR10MB031490544492486E47D2694DFA250@CY1PR10MB0314.namprd10.prod.outlook.com>
Message-ID: <CAD+L2cxLXzzc2X4YFeYegqbAqKM8uODxsuA7C3ZVhtX9pzQhbg@mail.gmail.com>

Make sure you are using Undertow 1.3.23.Final, there were some fixes
here recently.

Stuart

On Sat, Jul 2, 2016 at 4:02 AM, PingShan Li <ping.li at firemon.com> wrote:
> Based on your suggestion, we are able to add extension
> PerMessageDeflateHandshake to WebSocketDeploymentInfo.
>
> In the constructor of the ServerWebSocketContainer, the installedExtensions
> has one element of PerMessageDeflateHandshake. But when the
> getInstalledExtensions is called, it still returns empty set, should that
> function return installedExtensions instead of Collections.emptySet()?
>
>     public ServerWebSocketContainer(final ClassIntrospecter
> classIntrospecter, final ClassLoader classLoader, XnioWorker xnioWorker,
> ByteBufferPool bufferPool, ThreadSetupAction threadSetupAction, boolean
> dispatchToWorker, InetSocketAddress clientBindAddress,
> WebSocketReconnectHandler reconnectHandler, List<Extension>
> installedExtensions) {
>         this.classIntrospecter = classIntrospecter;
>         this.bufferPool = bufferPool;
>         this.xnioWorker = xnioWorker;
>         this.threadSetupAction = threadSetupAction;
>         this.dispatchToWorker = dispatchToWorker;
>         this.clientBindAddress = clientBindAddress;
>         this.installedExtensions = new ArrayList<>(installedExtensions);
>         List<WebsocketClientSslProvider> clientSslProviders = new
> ArrayList<>();
>         for (WebsocketClientSslProvider provider :
> ServiceLoader.load(WebsocketClientSslProvider.class, classLoader)) {
>             clientSslProviders.add(provider);
>         }
>
>         this.clientSslProviders =
> Collections.unmodifiableList(clientSslProviders);
>         this.webSocketReconnectHandler = reconnectHandler;
>     }
>
>     public Set<Extension> getInstalledExtensions() {
>         return Collections.emptySet();
>     }
>
>
> ________________________________
> From: Stuart Douglas <sdouglas at redhat.com>
> Sent: Wednesday, June 29, 2016 7:00:31 PM
> To: PingShan Li
> Cc: undertow-dev at lists.jboss.org
> Subject: Re: [undertow-dev] permessage-deflate extension is not supported,
> getInstalledExtensions() returns empty set in ServerWebSocketContainer.java
>
> You need to invoke
> io.undertow.websockets.jsr.WebSocketDeploymentInfo#addExtension with
> an instance of io.undertow.websockets.extensions.PerMessageDeflateHandshake
>
>
> Stuart
>
> On Thu, Jun 30, 2016 at 6:16 AM, PingShan Li <ping.li at firemon.com> wrote:
>> --- Problem:
>> client's request for compression is ignored.
>>
>> The client sends the request for compression:
>>
>> Sec-WebSocket-Extensions: permessage-deflate; client_no_context_takeover;
>> client_max_window_bits\r\n
>>
>>
>> Webserver receives the client request,
>>
>>
>>
>> org.springframework.web.socket.server.support.AbstractHandshakeHandler.java:
>>
>> doHandshake function: try to see if requested extension is supported
>>
>> String subProtocol = selectProtocol(headers.getSecWebSocketProtocol(),
>> wsHandler);
>> List<WebSocketExtension> requested = headers.getSecWebSocketExtensions();
>> List<WebSocketExtension> supported =
>> this.requestUpgradeStrategy.getSupportedExtensions(request);
>> List<WebSocketExtension> extensions = filterRequestedExtensions(request,
>> requested, supported);
>>
>> getSupportedExtensions calls into the following function, which always
>> returns empty set for installed extensions.
>>
>> io.undertow.websockets.jsr.ServerWebSocketContainer.java:
>>
>>     public Set<Extension> getInstalledExtensions() {
>>         return Collections.emptySet();
>>     }
>>
>> My question is:
>> how to tell spring framework that the permessage-deflate extension is
>> supported by undertow?
>>
>> Environement:
>> Undertow 1.3.22 Final is used by springframework:
>> +-
>>
>> org.springframework.boot:spring-boot-starter-undertow:jar:1.3.5.RELEASE:compile
>> [INFO] |  |  +- io.undertow:undertow-core:jar:1.3.22.Final:compile
>> [INFO] |  |  +- io.undertow:undertow-servlet:jar:1.3.22.Final:compile
>> [INFO] |  |  +-
>> io.undertow:undertow-websockets-jsr:jar:1.3.22.Final:compile
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev

From oliver at analyticspot.com  Mon Jul  4 20:29:14 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Tue, 05 Jul 2016 00:29:14 +0000
Subject: [undertow-dev] Asynchronous AuthenticationMechanism
Message-ID: <CACSC6EWe=-S3qjdbZDpX2ZeKY6sNp4qU3ZPJcd7xHbsjtBuqaA@mail.gmail.com>

The docs for security (
http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#security)
say:

> Security within Undertow is implemented as a set of asynchronous handlers
and a set of authentication mechanisms co-ordinated by these handlers.

However, it appears that the IdentityManager and AuthenticationMechanism
APIs are synchronous. For example, suppose I want to do simple
username/password authentication using FormAuthenticationMechanism. That
will use the IdentityManager on the SecurityContext to determine if the
username/password is valid. For me that would require a database lookup and
I'd like to do that asynchronously. However, the IdentityManager.verify API
requires an immediate response so I have to do a block database lookup.
Since I've been super careful to do everything in all my handlers async and
have exactly 1 thread per core this seems like a significant stumbling
block.

2 questions:

1. Is there a way to do something like I'm describing in an async manner?
2. Why is security "special" using a SecurityContext, different APIs, etc.
Couldn't it all have been implemented in terms of regular HttpHandler? That
would make it the API smaller and make it possible to do async
authentication.

Thanks,
Oliver
-- 
CTO, Analytic Spot
44 West Broadway #222
Eugene, OR 97401
analyticspot.com ? 425-296-6556
www.linkedin.com/in/oliverdain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160705/1054b84e/attachment-0001.html 

From electrotype at gmail.com  Mon Jul  4 20:43:12 2016
From: electrotype at gmail.com (electrotype)
Date: Mon, 4 Jul 2016 20:43:12 -0400
Subject: [undertow-dev] Redirects during the handshake of a WebSocket
	upgrade request
Message-ID: <389cf90a-2acf-b9f8-f54a-2f59e059a60c@gmail.com>

Hi,

I see some people think the HTTP request for a WebSocket upgrade shouldn't honnor 301/302 redirects. 
But the spec seems to say it is ok:

"/If the status code received from the server is not 101, the//
//client handles the response per HTTP [RFC2616] procedures. In//
//particular, the client might perform authentication if it//
//receives a 401 status code; the server might redirect the client//
//using a 3xx status code (but clients are not required to follow//
//them), etc.  Otherwise, proceed as follows/."

"/The server MAY redirect the client using a 3xx status code//
//[RFC2616].  Note that this step can happen together with, before,//
//or after the optional authentication step described above./"

https://tools.ietf.org/html/rfc6455

In the version of Undertow I use, 1.2.12.Final, I see that the redirect response is handled by 
/org.xnio.http.HttpUpgrade/ :

private void handleRedirect(final HttpUpgradeParser parser) {
     List<String> location = parser.getHeaders().get("location");
     future.setException(new RedirectException(msg.redirect(), parser.getResponseCode(), location == 
null ? null : location.get(0)));
}

Is it the same behavior in most recent Undertow releases?

Related discussion: https://github.com/sta/websocket-sharp/issues/42

Thanks,

Julien


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

From sdouglas at redhat.com  Mon Jul  4 22:13:39 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 5 Jul 2016 12:13:39 +1000
Subject: [undertow-dev] Redirects during the handshake of a WebSocket
 upgrade request
In-Reply-To: <389cf90a-2acf-b9f8-f54a-2f59e059a60c@gmail.com>
References: <389cf90a-2acf-b9f8-f54a-2f59e059a60c@gmail.com>
Message-ID: <CAD+L2cwJV2CjJAEbr4h_n8gr5x0dNTSBUXi1OrP+kjx29htd5Q@mail.gmail.com>

Yes, Undertow should respect the redirect response code.

Stuart

On Tue, Jul 5, 2016 at 10:43 AM, electrotype <electrotype at gmail.com> wrote:
> Hi,
>
> I see some people think the HTTP request for a WebSocket upgrade shouldn't
> honnor 301/302 redirects. But the spec seems to say it is ok:
>
> "If the status code received from the server is not 101, the
> client handles the response per HTTP [RFC2616] procedures.  In
> particular, the client might perform authentication if it
> receives a 401 status code; the server might redirect the client
> using a 3xx status code (but clients are not required to follow
> them), etc.  Otherwise, proceed as follows."
>
> "The server MAY redirect the client using a 3xx status code
> [RFC2616].  Note that this step can happen together with, before,
> or after the optional authentication step described above."
>
> https://tools.ietf.org/html/rfc6455
>
> In the version of Undertow I use, 1.2.12.Final, I see that the redirect
> response is handled by org.xnio.http.HttpUpgrade :
>
> private void handleRedirect(final HttpUpgradeParser parser) {
>     List<String> location = parser.getHeaders().get("location");
>     future.setException(new RedirectException(msg.redirect(),
> parser.getResponseCode(), location == null ? null : location.get(0)));
> }
>
> Is it the same behavior in most recent Undertow releases?
>
> Related discussion: https://github.com/sta/websocket-sharp/issues/42
>
> Thanks,
>
> Julien
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From electrotype at gmail.com  Mon Jul  4 22:52:06 2016
From: electrotype at gmail.com (electrotype)
Date: Mon, 4 Jul 2016 22:52:06 -0400
Subject: [undertow-dev] Redirects during the handshake of a WebSocket
 upgrade request
In-Reply-To: <CAD+L2cwJV2CjJAEbr4h_n8gr5x0dNTSBUXi1OrP+kjx29htd5Q@mail.gmail.com>
References: <389cf90a-2acf-b9f8-f54a-2f59e059a60c@gmail.com>
	<CAD+L2cwJV2CjJAEbr4h_n8gr5x0dNTSBUXi1OrP+kjx29htd5Q@mail.gmail.com>
Message-ID: <a2808c65-e24f-c9f8-ee61-4e866a9bdcfb@gmail.com>

Are you saying it is something you will probably implement in a future release?

Is there an issue I can follow?

Thanks for the help.

Julien

On 2016-07-04 22:13, Stuart Douglas wrote:
> Yes, Undertow should respect the redirect response code.
>
> Stuart
>
> On Tue, Jul 5, 2016 at 10:43 AM, electrotype <electrotype at gmail.com> wrote:
>> Hi,
>>
>> I see some people think the HTTP request for a WebSocket upgrade shouldn't
>> honnor 301/302 redirects. But the spec seems to say it is ok:
>>
>> "If the status code received from the server is not 101, the
>> client handles the response per HTTP [RFC2616] procedures.  In
>> particular, the client might perform authentication if it
>> receives a 401 status code; the server might redirect the client
>> using a 3xx status code (but clients are not required to follow
>> them), etc.  Otherwise, proceed as follows."
>>
>> "The server MAY redirect the client using a 3xx status code
>> [RFC2616].  Note that this step can happen together with, before,
>> or after the optional authentication step described above."
>>
>> https://tools.ietf.org/html/rfc6455
>>
>> In the version of Undertow I use, 1.2.12.Final, I see that the redirect
>> response is handled by org.xnio.http.HttpUpgrade :
>>
>> private void handleRedirect(final HttpUpgradeParser parser) {
>>      List<String> location = parser.getHeaders().get("location");
>>      future.setException(new RedirectException(msg.redirect(),
>> parser.getResponseCode(), location == null ? null : location.get(0)));
>> }
>>
>> Is it the same behavior in most recent Undertow releases?
>>
>> Related discussion: https://github.com/sta/websocket-sharp/issues/42
>>
>> Thanks,
>>
>> Julien
>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Mon Jul  4 23:32:44 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 5 Jul 2016 13:32:44 +1000
Subject: [undertow-dev] Redirects during the handshake of a WebSocket
 upgrade request
In-Reply-To: <a2808c65-e24f-c9f8-ee61-4e866a9bdcfb@gmail.com>
References: <389cf90a-2acf-b9f8-f54a-2f59e059a60c@gmail.com>
	<CAD+L2cwJV2CjJAEbr4h_n8gr5x0dNTSBUXi1OrP+kjx29htd5Q@mail.gmail.com>
	<a2808c65-e24f-c9f8-ee61-4e866a9bdcfb@gmail.com>
Message-ID: <CAD+L2cwPd7vMo6-kEHj2nP_F1q5m+acKAnzdZRj1HPxr+QCqyg@mail.gmail.com>

Looks like this was an oversight, we added support for this in the
Wildfly HTTP upgrade support, but not websockets.

I have added support for this into the 1.4.x and 2.0.x branches
(https://issues.jboss.org/browse/UNDERTOW-760).

Stuart

On Tue, Jul 5, 2016 at 12:52 PM, electrotype <electrotype at gmail.com> wrote:
> Are you saying it is something you will probably implement in a future release?
>
> Is there an issue I can follow?
>
> Thanks for the help.
>
> Julien
>
> On 2016-07-04 22:13, Stuart Douglas wrote:
>> Yes, Undertow should respect the redirect response code.
>>
>> Stuart
>>
>> On Tue, Jul 5, 2016 at 10:43 AM, electrotype <electrotype at gmail.com> wrote:
>>> Hi,
>>>
>>> I see some people think the HTTP request for a WebSocket upgrade shouldn't
>>> honnor 301/302 redirects. But the spec seems to say it is ok:
>>>
>>> "If the status code received from the server is not 101, the
>>> client handles the response per HTTP [RFC2616] procedures.  In
>>> particular, the client might perform authentication if it
>>> receives a 401 status code; the server might redirect the client
>>> using a 3xx status code (but clients are not required to follow
>>> them), etc.  Otherwise, proceed as follows."
>>>
>>> "The server MAY redirect the client using a 3xx status code
>>> [RFC2616].  Note that this step can happen together with, before,
>>> or after the optional authentication step described above."
>>>
>>> https://tools.ietf.org/html/rfc6455
>>>
>>> In the version of Undertow I use, 1.2.12.Final, I see that the redirect
>>> response is handled by org.xnio.http.HttpUpgrade :
>>>
>>> private void handleRedirect(final HttpUpgradeParser parser) {
>>>      List<String> location = parser.getHeaders().get("location");
>>>      future.setException(new RedirectException(msg.redirect(),
>>> parser.getResponseCode(), location == null ? null : location.get(0)));
>>> }
>>>
>>> Is it the same behavior in most recent Undertow releases?
>>>
>>> Related discussion: https://github.com/sta/websocket-sharp/issues/42
>>>
>>> Thanks,
>>>
>>> Julien
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 electrotype at gmail.com  Tue Jul  5 08:21:47 2016
From: electrotype at gmail.com (electrotype)
Date: Tue, 5 Jul 2016 08:21:47 -0400
Subject: [undertow-dev] Redirects during the handshake of a WebSocket
 upgrade request
In-Reply-To: <CAD+L2cwPd7vMo6-kEHj2nP_F1q5m+acKAnzdZRj1HPxr+QCqyg@mail.gmail.com>
References: <389cf90a-2acf-b9f8-f54a-2f59e059a60c@gmail.com>
	<CAD+L2cwJV2CjJAEbr4h_n8gr5x0dNTSBUXi1OrP+kjx29htd5Q@mail.gmail.com>
	<a2808c65-e24f-c9f8-ee61-4e866a9bdcfb@gmail.com>
	<CAD+L2cwPd7vMo6-kEHj2nP_F1q5m+acKAnzdZRj1HPxr+QCqyg@mail.gmail.com>
Message-ID: <1a9964dc-47be-f18e-874d-0fe08e4a6b84@gmail.com>

Thanks Stuart.

Julien

On 2016-07-04 23:32, Stuart Douglas wrote:
> Looks like this was an oversight, we added support for this in the
> Wildfly HTTP upgrade support, but not websockets.
>
> I have added support for this into the 1.4.x and 2.0.x branches
> (https://issues.jboss.org/browse/UNDERTOW-760).
>
> Stuart
>
> On Tue, Jul 5, 2016 at 12:52 PM, electrotype <electrotype at gmail.com> wrote:
>> Are you saying it is something you will probably implement in a future release?
>>
>> Is there an issue I can follow?
>>
>> Thanks for the help.
>>
>> Julien
>>
>> On 2016-07-04 22:13, Stuart Douglas wrote:
>>> Yes, Undertow should respect the redirect response code.
>>>
>>> Stuart
>>>
>>> On Tue, Jul 5, 2016 at 10:43 AM, electrotype <electrotype at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I see some people think the HTTP request for a WebSocket upgrade shouldn't
>>>> honnor 301/302 redirects. But the spec seems to say it is ok:
>>>>
>>>> "If the status code received from the server is not 101, the
>>>> client handles the response per HTTP [RFC2616] procedures.  In
>>>> particular, the client might perform authentication if it
>>>> receives a 401 status code; the server might redirect the client
>>>> using a 3xx status code (but clients are not required to follow
>>>> them), etc.  Otherwise, proceed as follows."
>>>>
>>>> "The server MAY redirect the client using a 3xx status code
>>>> [RFC2616].  Note that this step can happen together with, before,
>>>> or after the optional authentication step described above."
>>>>
>>>> https://tools.ietf.org/html/rfc6455
>>>>
>>>> In the version of Undertow I use, 1.2.12.Final, I see that the redirect
>>>> response is handled by org.xnio.http.HttpUpgrade :
>>>>
>>>> private void handleRedirect(final HttpUpgradeParser parser) {
>>>>       List<String> location = parser.getHeaders().get("location");
>>>>       future.setException(new RedirectException(msg.redirect(),
>>>> parser.getResponseCode(), location == null ? null : location.get(0)));
>>>> }
>>>>
>>>> Is it the same behavior in most recent Undertow releases?
>>>>
>>>> Related discussion: https://github.com/sta/websocket-sharp/issues/42
>>>>
>>>> Thanks,
>>>>
>>>> Julien
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Tue Jul  5 18:56:09 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 6 Jul 2016 08:56:09 +1000
Subject: [undertow-dev] Asynchronous AuthenticationMechanism
In-Reply-To: <CACSC6EWe=-S3qjdbZDpX2ZeKY6sNp4qU3ZPJcd7xHbsjtBuqaA@mail.gmail.com>
References: <CACSC6EWe=-S3qjdbZDpX2ZeKY6sNp4qU3ZPJcd7xHbsjtBuqaA@mail.gmail.com>
Message-ID: <CAD+L2cxGjwPTPzt9kBvbZZUKj=bkM4BRdnFy+EfqjvzeeBM8UA@mail.gmail.com>

The issue with a database is that there is basically no way to do an
async lookup with JDBC. It is possible the DB might provide async
drivers that you can use.

The main reason why the IdentityManager uses a blocking API is because
the vast majority of java implementations will be blocking (databases,
ldap etc), although we may look at doing a non blocking version at
some point in the future.

There is actually nothing really 'special' about SecurityContext,
IdentityManager etc, its just that the existing security handlers (and
most importantly Servlet security) are implemented in terms of this.
Depending on your requirements you can replace part or all of this.
For example you could use a handler earlier in the chain to verify the
user via a non blocking DB lookup, then just call
SecurityContext.authenticationComplete() to set the current user if
you want to use the existing security handlers.

Stuart

On Tue, Jul 5, 2016 at 10:29 AM, Oliver Dain <oliver at analyticspot.com> wrote:
> The docs for security
> (http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#security)
> say:
>
>> Security within Undertow is implemented as a set of asynchronous handlers
>> and a set of authentication mechanisms co-ordinated by these handlers.
>
> However, it appears that the IdentityManager and AuthenticationMechanism
> APIs are synchronous. For example, suppose I want to do simple
> username/password authentication using FormAuthenticationMechanism. That
> will use the IdentityManager on the SecurityContext to determine if the
> username/password is valid. For me that would require a database lookup and
> I'd like to do that asynchronously. However, the IdentityManager.verify API
> requires an immediate response so I have to do a block database lookup.
> Since I've been super careful to do everything in all my handlers async and
> have exactly 1 thread per core this seems like a significant stumbling
> block.
>
> 2 questions:
>
> 1. Is there a way to do something like I'm describing in an async manner?
> 2. Why is security "special" using a SecurityContext, different APIs, etc.
> Couldn't it all have been implemented in terms of regular HttpHandler? That
> would make it the API smaller and make it possible to do async
> authentication.
>
> Thanks,
> Oliver
> --
> CTO, Analytic Spot
> 44 West Broadway #222
> Eugene, OR 97401
> analyticspot.com ? 425-296-6556
> www.linkedin.com/in/oliverdain
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From oliver at analyticspot.com  Tue Jul  5 20:43:05 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Wed, 06 Jul 2016 00:43:05 +0000
Subject: [undertow-dev] Asynchronous AuthenticationMechanism
In-Reply-To: <CAD+L2cxGjwPTPzt9kBvbZZUKj=bkM4BRdnFy+EfqjvzeeBM8UA@mail.gmail.com>
References: <CACSC6EWe=-S3qjdbZDpX2ZeKY6sNp4qU3ZPJcd7xHbsjtBuqaA@mail.gmail.com>
	<CAD+L2cxGjwPTPzt9kBvbZZUKj=bkM4BRdnFy+EfqjvzeeBM8UA@mail.gmail.com>
Message-ID: <CACSC6EWNxDk-rN44GzRVKLMU0_bnFnp9tnU_WZj8_yc9B8BQ-w@mail.gmail.com>

Hey Stuart,

Thanks for the reply. We're using Cassandra so we have a good, async data
store and would love to be able to take advantage of it. I'll have to look
at the existing security stuff to see if it's easier to just implement as
standard handlers or to mix-and-match as you suggest. I would like to be
able to use some of the existing AuthenticationMechanism code rather than
re-implement, but I think I can actually write a small wrapper that lets me
call them from a regular handler rather than the other way around.

Thanks,
Oliver

On Tue, Jul 5, 2016 at 3:56 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> The issue with a database is that there is basically no way to do an
> async lookup with JDBC. It is possible the DB might provide async
> drivers that you can use.
>
> The main reason why the IdentityManager uses a blocking API is because
> the vast majority of java implementations will be blocking (databases,
> ldap etc), although we may look at doing a non blocking version at
> some point in the future.
>
> There is actually nothing really 'special' about SecurityContext,
> IdentityManager etc, its just that the existing security handlers (and
> most importantly Servlet security) are implemented in terms of this.
> Depending on your requirements you can replace part or all of this.
> For example you could use a handler earlier in the chain to verify the
> user via a non blocking DB lookup, then just call
> SecurityContext.authenticationComplete() to set the current user if
> you want to use the existing security handlers.
>
> Stuart
>
> On Tue, Jul 5, 2016 at 10:29 AM, Oliver Dain <oliver at analyticspot.com>
> wrote:
> > The docs for security
> > (
> http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#security)
> > say:
> >
> >> Security within Undertow is implemented as a set of asynchronous
> handlers
> >> and a set of authentication mechanisms co-ordinated by these handlers.
> >
> > However, it appears that the IdentityManager and AuthenticationMechanism
> > APIs are synchronous. For example, suppose I want to do simple
> > username/password authentication using FormAuthenticationMechanism. That
> > will use the IdentityManager on the SecurityContext to determine if the
> > username/password is valid. For me that would require a database lookup
> and
> > I'd like to do that asynchronously. However, the IdentityManager.verify
> API
> > requires an immediate response so I have to do a block database lookup.
> > Since I've been super careful to do everything in all my handlers async
> and
> > have exactly 1 thread per core this seems like a significant stumbling
> > block.
> >
> > 2 questions:
> >
> > 1. Is there a way to do something like I'm describing in an async manner?
> > 2. Why is security "special" using a SecurityContext, different APIs,
> etc.
> > Couldn't it all have been implemented in terms of regular HttpHandler?
> That
> > would make it the API smaller and make it possible to do async
> > authentication.
> >
> > Thanks,
> > Oliver
> > --
> > CTO, Analytic Spot
> > 44 West Broadway #222
> > Eugene, OR 97401
> > analyticspot.com ? 425-296-6556
> > www.linkedin.com/in/oliverdain
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-- 
CTO, Analytic Spot
44 West Broadway #222
Eugene, OR 97401
analyticspot.com ? 425-296-6556
www.linkedin.com/in/oliverdain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160706/f85d1dd6/attachment.html 

From peter.royal at pobox.com  Wed Jul  6 16:56:03 2016
From: peter.royal at pobox.com (peter royal)
Date: Wed, 06 Jul 2016 15:56:03 -0500
Subject: [undertow-dev] WebSocket sending back pressure
Message-ID: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>

I am finding that sometimes I have WebSocket connections that are unable
to flush messages out the socket at the rate I am generating messages.

I'm using the core.WebSockets class to send messages. Is it possible to
achieve this with what exists currently? My initial guess is no..
conceptually it would be nice for core.WebSockets to return a
CompletableFuture-style object that would let me get a callback when the
message is sent, or have the ability to cancel it if it is still sitting
in the send queue.

I'm happy to help build something into Undertow if it is a welcome
addition.

-pete

-- 
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

From sdouglas at redhat.com  Wed Jul  6 22:43:15 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 7 Jul 2016 12:43:15 +1000
Subject: [undertow-dev] WebSocket sending back pressure
In-Reply-To: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
References: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
Message-ID: <CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>

Some of the methods take a WebSocketCallback that will notify you on
completion or error, however at the moment there is no way to cancel a
message.

Stuart

On Thu, Jul 7, 2016 at 6:56 AM, peter royal <peter.royal at pobox.com> wrote:
> I am finding that sometimes I have WebSocket connections that are unable
> to flush messages out the socket at the rate I am generating messages.
>
> I'm using the core.WebSockets class to send messages. Is it possible to
> achieve this with what exists currently? My initial guess is no..
> conceptually it would be nice for core.WebSockets to return a
> CompletableFuture-style object that would let me get a callback when the
> message is sent, or have the ability to cancel it if it is still sitting
> in the send queue.
>
> I'm happy to help build something into Undertow if it is a welcome
> addition.
>
> -pete
>
> --
> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From peter.royal at pobox.com  Thu Jul  7 08:08:32 2016
From: peter.royal at pobox.com (peter royal)
Date: Thu, 07 Jul 2016 07:08:32 -0500
Subject: [undertow-dev] WebSocket sending back pressure
In-Reply-To: <CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>
References: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
	<CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>
Message-ID: <1467893312.2860667.659437769.60E835FB@webmail.messagingengine.com>

I looked some more and cancellation would be a huge change - I'm going
to see how far I can get by using the existing callback for flow
control.

-pete

-- 
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

On Wed, Jul 6, 2016, at 09:43 PM, Stuart Douglas wrote:
> Some of the methods take a WebSocketCallback that will notify you on
> completion or error, however at the moment there is no way to cancel a
> message.
> 
> Stuart
> 
> On Thu, Jul 7, 2016 at 6:56 AM, peter royal <peter.royal at pobox.com>
> wrote:
> > I am finding that sometimes I have WebSocket connections that are unable
> > to flush messages out the socket at the rate I am generating messages.
> >
> > I'm using the core.WebSockets class to send messages. Is it possible to
> > achieve this with what exists currently? My initial guess is no..
> > conceptually it would be nice for core.WebSockets to return a
> > CompletableFuture-style object that would let me get a callback when the
> > message is sent, or have the ability to cancel it if it is still sitting
> > in the send queue.
> >
> > I'm happy to help build something into Undertow if it is a welcome
> > addition.
> >
> > -pete
> >
> > --
> > (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev

From jason.greene at redhat.com  Thu Jul  7 08:13:25 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 7 Jul 2016 08:13:25 -0400 (EDT)
Subject: [undertow-dev] WebSocket sending back pressure
In-Reply-To: <1467893312.2860667.659437769.60E835FB@webmail.messagingengine.com>
References: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
	<CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>
	<1467893312.2860667.659437769.60E835FB@webmail.messagingengine.com>
Message-ID: <0CE130E9-7415-487F-8B09-DEF39FF26E69@redhat.com>

There is also a flush method on the channel if it's helpful.

> On Jul 7, 2016, at 7:10 AM, peter royal <peter.royal at pobox.com> wrote:
> 
> I looked some more and cancellation would be a huge change - I'm going
> to see how far I can get by using the existing callback for flow
> control.
> 
> -pete
> 
> -- 
> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> 
>> On Wed, Jul 6, 2016, at 09:43 PM, Stuart Douglas wrote:
>> Some of the methods take a WebSocketCallback that will notify you on
>> completion or error, however at the moment there is no way to cancel a
>> message.
>> 
>> Stuart
>> 
>> On Thu, Jul 7, 2016 at 6:56 AM, peter royal <peter.royal at pobox.com>
>> wrote:
>>> I am finding that sometimes I have WebSocket connections that are unable
>>> to flush messages out the socket at the rate I am generating messages.
>>> 
>>> I'm using the core.WebSockets class to send messages. Is it possible to
>>> achieve this with what exists currently? My initial guess is no..
>>> conceptually it would be nice for core.WebSockets to return a
>>> CompletableFuture-style object that would let me get a callback when the
>>> message is sent, or have the ability to cancel it if it is still sitting
>>> in the send queue.
>>> 
>>> I'm happy to help build something into Undertow if it is a welcome
>>> addition.
>>> 
>>> -pete
>>> 
>>> --
>>> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
>>> _______________________________________________
>>> 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 peter.royal at pobox.com  Thu Jul  7 08:27:11 2016
From: peter.royal at pobox.com (peter royal)
Date: Thu, 07 Jul 2016 07:27:11 -0500
Subject: [undertow-dev] WebSocket sending back pressure
In-Reply-To: <0CE130E9-7415-487F-8B09-DEF39FF26E69@redhat.com>
References: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
	<CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>
	<1467893312.2860667.659437769.60E835FB@webmail.messagingengine.com>
	<0CE130E9-7415-487F-8B09-DEF39FF26E69@redhat.com>
Message-ID: <1467894431.2864946.659446681.084918DC@webmail.messagingengine.com>

The flush method on *FrameSinkChannel channels? I could use that to see
if a message had been sent, but how might that be incorporated into a
back pressure algorithm? 

At my application level I have the notion of a 'topic' that a WS message
is sent on. For most topics only the most recent message is the one that
matters. For those topics I was going to use the WebSocketCallback to
only allow one at a time to be queued on the WebSocketChannel.

-pete

-- 
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

On Thu, Jul 7, 2016, at 07:13 AM, Jason T. Greene wrote:
> There is also a flush method on the channel if it's helpful.
> 
> > On Jul 7, 2016, at 7:10 AM, peter royal <peter.royal at pobox.com> wrote:
> > 
> > I looked some more and cancellation would be a huge change - I'm going
> > to see how far I can get by using the existing callback for flow
> > control.
> > 
> > -pete
> > 
> > -- 
> > (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> > 
> >> On Wed, Jul 6, 2016, at 09:43 PM, Stuart Douglas wrote:
> >> Some of the methods take a WebSocketCallback that will notify you on
> >> completion or error, however at the moment there is no way to cancel a
> >> message.
> >> 
> >> Stuart
> >> 
> >> On Thu, Jul 7, 2016 at 6:56 AM, peter royal <peter.royal at pobox.com>
> >> wrote:
> >>> I am finding that sometimes I have WebSocket connections that are unable
> >>> to flush messages out the socket at the rate I am generating messages.
> >>> 
> >>> I'm using the core.WebSockets class to send messages. Is it possible to
> >>> achieve this with what exists currently? My initial guess is no..
> >>> conceptually it would be nice for core.WebSockets to return a
> >>> CompletableFuture-style object that would let me get a callback when the
> >>> message is sent, or have the ability to cancel it if it is still sitting
> >>> in the send queue.
> >>> 
> >>> I'm happy to help build something into Undertow if it is a welcome
> >>> addition.
> >>> 
> >>> -pete
> >>> 
> >>> --
> >>> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Thu Jul  7 20:25:26 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 8 Jul 2016 10:25:26 +1000
Subject: [undertow-dev] WebSocket sending back pressure
In-Reply-To: <1467894431.2864946.659446681.084918DC@webmail.messagingengine.com>
References: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
	<CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>
	<1467893312.2860667.659437769.60E835FB@webmail.messagingengine.com>
	<0CE130E9-7415-487F-8B09-DEF39FF26E69@redhat.com>
	<1467894431.2864946.659446681.084918DC@webmail.messagingengine.com>
Message-ID: <CAD+L2cxmZ0pBaxvR9DMjryhvTGHeswO5rUgc7O=QgzzhSJVtiA@mail.gmail.com>

Cancellation might be possible to implement, however obviosly once the
message has actually started sending it will no longer be possible to
cancel.

If you create a JIRA I will look into it.

Stuart

On Thu, Jul 7, 2016 at 10:27 PM, peter royal <peter.royal at pobox.com> wrote:
> The flush method on *FrameSinkChannel channels? I could use that to see
> if a message had been sent, but how might that be incorporated into a
> back pressure algorithm?
>
> At my application level I have the notion of a 'topic' that a WS message
> is sent on. For most topics only the most recent message is the one that
> matters. For those topics I was going to use the WebSocketCallback to
> only allow one at a time to be queued on the WebSocketChannel.
>
> -pete
>
> --
> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
>
> On Thu, Jul 7, 2016, at 07:13 AM, Jason T. Greene wrote:
>> There is also a flush method on the channel if it's helpful.
>>
>> > On Jul 7, 2016, at 7:10 AM, peter royal <peter.royal at pobox.com> wrote:
>> >
>> > I looked some more and cancellation would be a huge change - I'm going
>> > to see how far I can get by using the existing callback for flow
>> > control.
>> >
>> > -pete
>> >
>> > --
>> > (peter.royal|osi)@pobox.com - http://fotap.org/~osi
>> >
>> >> On Wed, Jul 6, 2016, at 09:43 PM, Stuart Douglas wrote:
>> >> Some of the methods take a WebSocketCallback that will notify you on
>> >> completion or error, however at the moment there is no way to cancel a
>> >> message.
>> >>
>> >> Stuart
>> >>
>> >> On Thu, Jul 7, 2016 at 6:56 AM, peter royal <peter.royal at pobox.com>
>> >> wrote:
>> >>> I am finding that sometimes I have WebSocket connections that are unable
>> >>> to flush messages out the socket at the rate I am generating messages.
>> >>>
>> >>> I'm using the core.WebSockets class to send messages. Is it possible to
>> >>> achieve this with what exists currently? My initial guess is no..
>> >>> conceptually it would be nice for core.WebSockets to return a
>> >>> CompletableFuture-style object that would let me get a callback when the
>> >>> message is sent, or have the ability to cancel it if it is still sitting
>> >>> in the send queue.
>> >>>
>> >>> I'm happy to help build something into Undertow if it is a welcome
>> >>> addition.
>> >>>
>> >>> -pete
>> >>>
>> >>> --
>> >>> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
>> >>> _______________________________________________
>> >>> 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 chandru.in at gmail.com  Fri Jul  8 08:20:42 2016
From: chandru.in at gmail.com (Chandru)
Date: Fri, 8 Jul 2016 17:50:42 +0530
Subject: [undertow-dev] Is a large number of IO threads acceptable?
Message-ID: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>

If I have a HTTP service where every request requires a blocking JDBC call,
is it acceptable to increase the number of IO threads to a large value
(say, 10*cores) instead of dispatching to worker thread pool on each
request?

Will configuring such a large number of IO threads lead to any adverse
effect on throughput or latency?

--
Chandra Sekar.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160708/1d85582d/attachment.html 

From bill at dartalley.com  Fri Jul  8 08:24:09 2016
From: bill at dartalley.com (Bill O'Neil)
Date: Fri, 8 Jul 2016 08:24:09 -0400
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
Message-ID: <CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>

This is exactly what the worker thread pool is built for why would you want
to use the IO threads instead? The IO threads are for reading / writing to
the socket of the HTTP request. All blocking operations SHOULD be
dispatched to worker threads.

On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:

> If I have a HTTP service where every request requires a blocking JDBC
> call, is it acceptable to increase the number of IO threads to a large
> value (say, 10*cores) instead of dispatching to worker thread pool on each
> request?
>
> Will configuring such a large number of IO threads lead to any adverse
> effect on throughput or latency?
>
> --
> Chandra Sekar.S
>
> _______________________________________________
> 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/20160708/b87fdefe/attachment.html 

From chandru.in at gmail.com  Fri Jul  8 08:31:19 2016
From: chandru.in at gmail.com (Chandru)
Date: Fri, 8 Jul 2016 18:01:19 +0530
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
Message-ID: <CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>

My line of thought was, if every request requires a blocking DB call, why
incur the cost of switching threads within a request, if I can instead
simply increase the number of IO threads without any adverse effect.

--
Chandra Sekar.S

On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com> wrote:

> This is exactly what the worker thread pool is built for why would you
> want to use the IO threads instead? The IO threads are for reading /
> writing to the socket of the HTTP request. All blocking operations SHOULD
> be dispatched to worker threads.
>
> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>
>> If I have a HTTP service where every request requires a blocking JDBC
>> call, is it acceptable to increase the number of IO threads to a large
>> value (say, 10*cores) instead of dispatching to worker thread pool on each
>> request?
>>
>> Will configuring such a large number of IO threads lead to any adverse
>> effect on throughput or latency?
>>
>> --
>> Chandra Sekar.S
>>
>> _______________________________________________
>> 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/20160708/2ecfe48b/attachment.html 

From bill at dartalley.com  Fri Jul  8 08:40:29 2016
From: bill at dartalley.com (Bill O'Neil)
Date: Fri, 8 Jul 2016 08:40:29 -0400
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
	<CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
Message-ID: <CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>

The cost of switching threads is fairly negligible. If you are concerned
about that level of performance then you are more likely to run into issues
using the on thread per connection model. If you use the 1 thread per
connection model you can only have that number of HTTP clients connected to
your web server at any given time. However with the IO / Worker thread
model you can have a low number of IO threads that accept a very large
number of concurrent connections which then queue up all of the blocking
requests for the workers to handle.

The thread per request model is like going back in time to tomcat days
where every webserver gets configured with hundreds to thousands of threads.

However if you don't have a higher number of concurrent users it
realistically shouldn't matter which way you choose. Just keep in mind the
thread per request model doesn't scale as far when you have blocking work.

On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in at gmail.com> wrote:

> My line of thought was, if every request requires a blocking DB call, why
> incur the cost of switching threads within a request, if I can instead
> simply increase the number of IO threads without any adverse effect.
>
> --
> Chandra Sekar.S
>
> On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com> wrote:
>
>> This is exactly what the worker thread pool is built for why would you
>> want to use the IO threads instead? The IO threads are for reading /
>> writing to the socket of the HTTP request. All blocking operations SHOULD
>> be dispatched to worker threads.
>>
>> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>>
>>> If I have a HTTP service where every request requires a blocking JDBC
>>> call, is it acceptable to increase the number of IO threads to a large
>>> value (say, 10*cores) instead of dispatching to worker thread pool on each
>>> request?
>>>
>>> Will configuring such a large number of IO threads lead to any adverse
>>> effect on throughput or latency?
>>>
>>> --
>>> Chandra Sekar.S
>>>
>>> _______________________________________________
>>> 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/20160708/e4c38697/attachment-0001.html 

From chandru.in at gmail.com  Fri Jul  8 08:46:32 2016
From: chandru.in at gmail.com (Chandru)
Date: Fri, 8 Jul 2016 18:16:32 +0530
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
	<CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
	<CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>
Message-ID: <CAAqDBcP3fX8=YJN+hWCkcSr28O6oi14HhcY5aywpO-EFuH_XsQ@mail.gmail.com>

Given every request requires a blocking IO call through JDBC, doesn't using
worker pool still boil down to thread per request, as requests will be
queued when all threads in the worker pool are blocked on JDBC?

--
Chandra Sekar.S

On Fri, Jul 8, 2016 at 6:10 PM, Bill O'Neil <bill at dartalley.com> wrote:

> The cost of switching threads is fairly negligible. If you are concerned
> about that level of performance then you are more likely to run into issues
> using the on thread per connection model. If you use the 1 thread per
> connection model you can only have that number of HTTP clients connected to
> your web server at any given time. However with the IO / Worker thread
> model you can have a low number of IO threads that accept a very large
> number of concurrent connections which then queue up all of the blocking
> requests for the workers to handle.
>
> The thread per request model is like going back in time to tomcat days
> where every webserver gets configured with hundreds to thousands of threads.
>
> However if you don't have a higher number of concurrent users it
> realistically shouldn't matter which way you choose. Just keep in mind the
> thread per request model doesn't scale as far when you have blocking work.
>
> On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in at gmail.com> wrote:
>
>> My line of thought was, if every request requires a blocking DB call, why
>> incur the cost of switching threads within a request, if I can instead
>> simply increase the number of IO threads without any adverse effect.
>>
>> --
>> Chandra Sekar.S
>>
>> On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>
>>> This is exactly what the worker thread pool is built for why would you
>>> want to use the IO threads instead? The IO threads are for reading /
>>> writing to the socket of the HTTP request. All blocking operations SHOULD
>>> be dispatched to worker threads.
>>>
>>> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>>>
>>>> If I have a HTTP service where every request requires a blocking JDBC
>>>> call, is it acceptable to increase the number of IO threads to a large
>>>> value (say, 10*cores) instead of dispatching to worker thread pool on each
>>>> request?
>>>>
>>>> Will configuring such a large number of IO threads lead to any adverse
>>>> effect on throughput or latency?
>>>>
>>>> --
>>>> Chandra Sekar.S
>>>>
>>>> _______________________________________________
>>>> 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/20160708/5b851ab7/attachment.html 

From bill at dartalley.com  Fri Jul  8 08:58:22 2016
From: bill at dartalley.com (Bill O'Neil)
Date: Fri, 8 Jul 2016 08:58:22 -0400
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CAAqDBcP3fX8=YJN+hWCkcSr28O6oi14HhcY5aywpO-EFuH_XsQ@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
	<CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
	<CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>
	<CAAqDBcP3fX8=YJN+hWCkcSr28O6oi14HhcY5aywpO-EFuH_XsQ@mail.gmail.com>
Message-ID: <CANd+gFzDQePNH0ev+vJm=ec4EBA+mJVzFUSi7vwtXxcaSiQQ4g@mail.gmail.com>

Basically the IO threads will open and manage the socket then push the
request into a queue for the workers. You can have 1000 HTTP requests
queued up to a worker thread pool that only has 10 threads (plus the 4-8 IO
threads). With the thread per request model you would need 1000 threads.
How you configure it all depends on the type of work that needs to be done.
Maybe you want a larger worker thread pool maybe you want a smaller one.
The benefit of splitting them out is you get more control.

Also keep in mind you should probably be using a JDBC connection pool. If
you have 1000 threads fighting over the limited number of JDBC connections
it will cause more contention than a much smaller number of worker threads.
JDBC connection pools generally have a much lower max number of connections
than the number of requests your web server accepts.

On Fri, Jul 8, 2016 at 8:46 AM, Chandru <chandru.in at gmail.com> wrote:

> Given every request requires a blocking IO call through JDBC, doesn't
> using worker pool still boil down to thread per request, as requests will
> be queued when all threads in the worker pool are blocked on JDBC?
>
> --
> Chandra Sekar.S
>
> On Fri, Jul 8, 2016 at 6:10 PM, Bill O'Neil <bill at dartalley.com> wrote:
>
>> The cost of switching threads is fairly negligible. If you are concerned
>> about that level of performance then you are more likely to run into issues
>> using the on thread per connection model. If you use the 1 thread per
>> connection model you can only have that number of HTTP clients connected to
>> your web server at any given time. However with the IO / Worker thread
>> model you can have a low number of IO threads that accept a very large
>> number of concurrent connections which then queue up all of the blocking
>> requests for the workers to handle.
>>
>> The thread per request model is like going back in time to tomcat days
>> where every webserver gets configured with hundreds to thousands of threads.
>>
>> However if you don't have a higher number of concurrent users it
>> realistically shouldn't matter which way you choose. Just keep in mind the
>> thread per request model doesn't scale as far when you have blocking work.
>>
>> On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in at gmail.com> wrote:
>>
>>> My line of thought was, if every request requires a blocking DB call,
>>> why incur the cost of switching threads within a request, if I can instead
>>> simply increase the number of IO threads without any adverse effect.
>>>
>>> --
>>> Chandra Sekar.S
>>>
>>> On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>>
>>>> This is exactly what the worker thread pool is built for why would you
>>>> want to use the IO threads instead? The IO threads are for reading /
>>>> writing to the socket of the HTTP request. All blocking operations SHOULD
>>>> be dispatched to worker threads.
>>>>
>>>> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>>>>
>>>>> If I have a HTTP service where every request requires a blocking JDBC
>>>>> call, is it acceptable to increase the number of IO threads to a large
>>>>> value (say, 10*cores) instead of dispatching to worker thread pool on each
>>>>> request?
>>>>>
>>>>> Will configuring such a large number of IO threads lead to any adverse
>>>>> effect on throughput or latency?
>>>>>
>>>>> --
>>>>> Chandra Sekar.S
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160708/4ca9e4b6/attachment.html 

From chandru.in at gmail.com  Fri Jul  8 09:04:47 2016
From: chandru.in at gmail.com (Chandru)
Date: Fri, 8 Jul 2016 18:34:47 +0530
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CANd+gFzDQePNH0ev+vJm=ec4EBA+mJVzFUSi7vwtXxcaSiQQ4g@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
	<CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
	<CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>
	<CAAqDBcP3fX8=YJN+hWCkcSr28O6oi14HhcY5aywpO-EFuH_XsQ@mail.gmail.com>
	<CANd+gFzDQePNH0ev+vJm=ec4EBA+mJVzFUSi7vwtXxcaSiQQ4g@mail.gmail.com>
Message-ID: <CAAqDBcM2Ae1eFSD6UHDPwni0kFr2_nAfL+jWNHESDDm=cQv7aA@mail.gmail.com>

So having separate pools allows HTTP requests to be parsed and queued for
processing even if all workers are blocked on JDBC calls, but their
processing still waits until worker threads are available. With just a
large IO pool even HTTP parsing will be blocked when all threads are
blocked on JDBC.

Have I got that right or am I missing other drawbacks?

Yes, I understand that having more threads then maximum active connections
in pool is futile.

--
Chandra Sekar.S

On Fri, Jul 8, 2016 at 6:28 PM, Bill O'Neil <bill at dartalley.com> wrote:

> Basically the IO threads will open and manage the socket then push the
> request into a queue for the workers. You can have 1000 HTTP requests
> queued up to a worker thread pool that only has 10 threads (plus the 4-8 IO
> threads). With the thread per request model you would need 1000 threads.
> How you configure it all depends on the type of work that needs to be done.
> Maybe you want a larger worker thread pool maybe you want a smaller one.
> The benefit of splitting them out is you get more control.
>
> Also keep in mind you should probably be using a JDBC connection pool. If
> you have 1000 threads fighting over the limited number of JDBC connections
> it will cause more contention than a much smaller number of worker threads.
> JDBC connection pools generally have a much lower max number of connections
> than the number of requests your web server accepts.
>
> On Fri, Jul 8, 2016 at 8:46 AM, Chandru <chandru.in at gmail.com> wrote:
>
>> Given every request requires a blocking IO call through JDBC, doesn't
>> using worker pool still boil down to thread per request, as requests will
>> be queued when all threads in the worker pool are blocked on JDBC?
>>
>> --
>> Chandra Sekar.S
>>
>> On Fri, Jul 8, 2016 at 6:10 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>
>>> The cost of switching threads is fairly negligible. If you are concerned
>>> about that level of performance then you are more likely to run into issues
>>> using the on thread per connection model. If you use the 1 thread per
>>> connection model you can only have that number of HTTP clients connected to
>>> your web server at any given time. However with the IO / Worker thread
>>> model you can have a low number of IO threads that accept a very large
>>> number of concurrent connections which then queue up all of the blocking
>>> requests for the workers to handle.
>>>
>>> The thread per request model is like going back in time to tomcat days
>>> where every webserver gets configured with hundreds to thousands of threads.
>>>
>>> However if you don't have a higher number of concurrent users it
>>> realistically shouldn't matter which way you choose. Just keep in mind the
>>> thread per request model doesn't scale as far when you have blocking work.
>>>
>>> On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in at gmail.com> wrote:
>>>
>>>> My line of thought was, if every request requires a blocking DB call,
>>>> why incur the cost of switching threads within a request, if I can instead
>>>> simply increase the number of IO threads without any adverse effect.
>>>>
>>>> --
>>>> Chandra Sekar.S
>>>>
>>>> On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>>>
>>>>> This is exactly what the worker thread pool is built for why would you
>>>>> want to use the IO threads instead? The IO threads are for reading /
>>>>> writing to the socket of the HTTP request. All blocking operations SHOULD
>>>>> be dispatched to worker threads.
>>>>>
>>>>> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>>>>>
>>>>>> If I have a HTTP service where every request requires a blocking JDBC
>>>>>> call, is it acceptable to increase the number of IO threads to a large
>>>>>> value (say, 10*cores) instead of dispatching to worker thread pool on each
>>>>>> request?
>>>>>>
>>>>>> Will configuring such a large number of IO threads lead to any
>>>>>> adverse effect on throughput or latency?
>>>>>>
>>>>>> --
>>>>>> Chandra Sekar.S
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160708/bf3f2d37/attachment-0001.html 

From bill at dartalley.com  Fri Jul  8 09:35:13 2016
From: bill at dartalley.com (Bill O'Neil)
Date: Fri, 8 Jul 2016 09:35:13 -0400
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CAAqDBcM2Ae1eFSD6UHDPwni0kFr2_nAfL+jWNHESDDm=cQv7aA@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
	<CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
	<CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>
	<CAAqDBcP3fX8=YJN+hWCkcSr28O6oi14HhcY5aywpO-EFuH_XsQ@mail.gmail.com>
	<CANd+gFzDQePNH0ev+vJm=ec4EBA+mJVzFUSi7vwtXxcaSiQQ4g@mail.gmail.com>
	<CAAqDBcM2Ae1eFSD6UHDPwni0kFr2_nAfL+jWNHESDDm=cQv7aA@mail.gmail.com>
Message-ID: <CANd+gFwTtDpjCDaseQZRZY=RZi44pURLsUazvYGmNFV9KqUswg@mail.gmail.com>

I'm about 95% confident that's how it works. I think Stuart will chime in
if I am incorrect.

Yes, I understand that having more threads then maximum active connections
> in pool is futile.

That's not always the case. In a distributed system you often want a lot
less connections than you might imagine. Take a look here it is very
informative.
https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

On Fri, Jul 8, 2016 at 9:04 AM, Chandru <chandru.in at gmail.com> wrote:

> So having separate pools allows HTTP requests to be parsed and queued for
> processing even if all workers are blocked on JDBC calls, but their
> processing still waits until worker threads are available. With just a
> large IO pool even HTTP parsing will be blocked when all threads are
> blocked on JDBC.
>
> Have I got that right or am I missing other drawbacks?
>
> Yes, I understand that having more threads then maximum active connections
> in pool is futile.
>
> --
> Chandra Sekar.S
>
> On Fri, Jul 8, 2016 at 6:28 PM, Bill O'Neil <bill at dartalley.com> wrote:
>
>> Basically the IO threads will open and manage the socket then push the
>> request into a queue for the workers. You can have 1000 HTTP requests
>> queued up to a worker thread pool that only has 10 threads (plus the 4-8 IO
>> threads). With the thread per request model you would need 1000 threads.
>> How you configure it all depends on the type of work that needs to be done.
>> Maybe you want a larger worker thread pool maybe you want a smaller one.
>> The benefit of splitting them out is you get more control.
>>
>> Also keep in mind you should probably be using a JDBC connection pool. If
>> you have 1000 threads fighting over the limited number of JDBC connections
>> it will cause more contention than a much smaller number of worker threads.
>> JDBC connection pools generally have a much lower max number of connections
>> than the number of requests your web server accepts.
>>
>> On Fri, Jul 8, 2016 at 8:46 AM, Chandru <chandru.in at gmail.com> wrote:
>>
>>> Given every request requires a blocking IO call through JDBC, doesn't
>>> using worker pool still boil down to thread per request, as requests will
>>> be queued when all threads in the worker pool are blocked on JDBC?
>>>
>>> --
>>> Chandra Sekar.S
>>>
>>> On Fri, Jul 8, 2016 at 6:10 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>>
>>>> The cost of switching threads is fairly negligible. If you are
>>>> concerned about that level of performance then you are more likely to run
>>>> into issues using the on thread per connection model. If you use the 1
>>>> thread per connection model you can only have that number of HTTP clients
>>>> connected to your web server at any given time. However with the IO /
>>>> Worker thread model you can have a low number of IO threads that accept a
>>>> very large number of concurrent connections which then queue up all of the
>>>> blocking requests for the workers to handle.
>>>>
>>>> The thread per request model is like going back in time to tomcat days
>>>> where every webserver gets configured with hundreds to thousands of threads.
>>>>
>>>> However if you don't have a higher number of concurrent users it
>>>> realistically shouldn't matter which way you choose. Just keep in mind the
>>>> thread per request model doesn't scale as far when you have blocking work.
>>>>
>>>> On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in at gmail.com> wrote:
>>>>
>>>>> My line of thought was, if every request requires a blocking DB call,
>>>>> why incur the cost of switching threads within a request, if I can instead
>>>>> simply increase the number of IO threads without any adverse effect.
>>>>>
>>>>> --
>>>>> Chandra Sekar.S
>>>>>
>>>>> On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com>
>>>>> wrote:
>>>>>
>>>>>> This is exactly what the worker thread pool is built for why would
>>>>>> you want to use the IO threads instead? The IO threads are for reading /
>>>>>> writing to the socket of the HTTP request. All blocking operations SHOULD
>>>>>> be dispatched to worker threads.
>>>>>>
>>>>>> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>>>>>>
>>>>>>> If I have a HTTP service where every request requires a blocking
>>>>>>> JDBC call, is it acceptable to increase the number of IO threads to a large
>>>>>>> value (say, 10*cores) instead of dispatching to worker thread pool on each
>>>>>>> request?
>>>>>>>
>>>>>>> Will configuring such a large number of IO threads lead to any
>>>>>>> adverse effect on throughput or latency?
>>>>>>>
>>>>>>> --
>>>>>>> Chandra Sekar.S
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/20160708/14133ffa/attachment.html 

From jason.greene at redhat.com  Fri Jul  8 09:51:23 2016
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 8 Jul 2016 09:51:23 -0400 (EDT)
Subject: [undertow-dev] Is a large number of IO threads acceptable?
In-Reply-To: <CAAqDBcM2Ae1eFSD6UHDPwni0kFr2_nAfL+jWNHESDDm=cQv7aA@mail.gmail.com>
References: <CAAqDBcNDUyETfiWp28JFf117P6QBtBSF3pKPq7iXVPFFpM+WrA@mail.gmail.com>
	<CANd+gFwA0C2QZ4PQ1cefqfC11NunLh+4AmyDw8atHeGsEk=hXA@mail.gmail.com>
	<CAAqDBcMATd0wnGyJj9+s98CMYuOP4AG18XhmE=X=-H27SGWhbA@mail.gmail.com>
	<CANd+gFxmPumFiXineiCvq41f5UXtNKEDwxvoYs-28T0J+9esTw@mail.gmail.com>
	<CAAqDBcP3fX8=YJN+hWCkcSr28O6oi14HhcY5aywpO-EFuH_XsQ@mail.gmail.com>
	<CANd+gFzDQePNH0ev+vJm=ec4EBA+mJVzFUSi7vwtXxcaSiQQ4g@mail.gmail.com>
	<CAAqDBcM2Ae1eFSD6UHDPwni0kFr2_nAfL+jWNHESDDm=cQv7aA@mail.gmail.com>
Message-ID: <88161B2A-5DBC-4963-8AF1-061BB50A60CC@redhat.com>



> On Jul 8, 2016, at 8:07 AM, Chandru <chandru.in at gmail.com> wrote:
> 
> So having separate pools allows HTTP requests to be parsed and queued for processing even if all workers are blocked on JDBC calls, but their processing still waits until worker threads are available. With just a large IO pool even HTTP parsing will be blocked when all threads are blocked on JDBC.

Yes but there is another major drawback. When you block an I/O thread you don't just block one connection, you block total connections / N, where N is the size of your I/O pool. So even if you make a pool size of say 50, if you have 1000 connections, then 20 connections are stuck making no progress you spend doing JDBC calls. 

With a separation of IO and worker, even if almost everything ends up in the worker, the server can still process a big chunk of activity in a non blocking fashion. Momentary idle connections, which is frequent considering most client activity is half duplex can be managed without dedicated threads. Also a great deal of server processing such as http processing, routing, redirection, proxying, etc can be done 


> 
> Have I got that right or am I missing other drawbacks?
> 
> Yes, I understand that having more threads then maximum active connections in pool is futile.
> 
> --
> Chandra Sekar.S
> 
>> On Fri, Jul 8, 2016 at 6:28 PM, Bill O'Neil <bill at dartalley.com> wrote:
>> Basically the IO threads will open and manage the socket then push the request into a queue for the workers. You can have 1000 HTTP requests queued up to a worker thread pool that only has 10 threads (plus the 4-8 IO threads). With the thread per request model you would need 1000 threads. How you configure it all depends on the type of work that needs to be done. Maybe you want a larger worker thread pool maybe you want a smaller one. The benefit of splitting them out is you get more control.
>> 
>> Also keep in mind you should probably be using a JDBC connection pool. If you have 1000 threads fighting over the limited number of JDBC connections it will cause more contention than a much smaller number of worker threads. JDBC connection pools generally have a much lower max number of connections than the number of requests your web server accepts.
>> 
>>> On Fri, Jul 8, 2016 at 8:46 AM, Chandru <chandru.in at gmail.com> wrote:
>>> Given every request requires a blocking IO call through JDBC, doesn't using worker pool still boil down to thread per request, as requests will be queued when all threads in the worker pool are blocked on JDBC?
>>> 
>>> --
>>> Chandra Sekar.S
>>> 
>>>> On Fri, Jul 8, 2016 at 6:10 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>>> The cost of switching threads is fairly negligible. If you are concerned about that level of performance then you are more likely to run into issues using the on thread per connection model. If you use the 1 thread per connection model you can only have that number of HTTP clients connected to your web server at any given time. However with the IO / Worker thread model you can have a low number of IO threads that accept a very large number of concurrent connections which then queue up all of the blocking requests for the workers to handle.
>>>> 
>>>> The thread per request model is like going back in time to tomcat days where every webserver gets configured with hundreds to thousands of threads.
>>>> 
>>>> However if you don't have a higher number of concurrent users it realistically shouldn't matter which way you choose. Just keep in mind the thread per request model doesn't scale as far when you have blocking work.
>>>> 
>>>>> On Fri, Jul 8, 2016 at 8:31 AM, Chandru <chandru.in at gmail.com> wrote:
>>>>> My line of thought was, if every request requires a blocking DB call, why incur the cost of switching threads within a request, if I can instead simply increase the number of IO threads without any adverse effect.
>>>>> 
>>>>> --
>>>>> Chandra Sekar.S
>>>>> 
>>>>>> On Fri, Jul 8, 2016 at 5:54 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>>>>> This is exactly what the worker thread pool is built for why would you want to use the IO threads instead? The IO threads are for reading / writing to the socket of the HTTP request. All blocking operations SHOULD be dispatched to worker threads.
>>>>>> 
>>>>>>> On Fri, Jul 8, 2016 at 8:20 AM, Chandru <chandru.in at gmail.com> wrote:
>>>>>>> If I have a HTTP service where every request requires a blocking JDBC call, is it acceptable to increase the number of IO threads to a large value (say, 10*cores) instead of dispatching to worker thread pool on each request?
>>>>>>> 
>>>>>>> Will configuring such a large number of IO threads lead to any adverse effect on throughput or latency?
>>>>>>> 
>>>>>>> --
>>>>>>> Chandra Sekar.S
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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/20160708/907486d5/attachment-0001.html 

From peter.royal at pobox.com  Fri Jul  8 09:57:02 2016
From: peter.royal at pobox.com (peter royal)
Date: Fri, 08 Jul 2016 08:57:02 -0500
Subject: [undertow-dev] WebSocket sending back pressure
In-Reply-To: <CAD+L2cxmZ0pBaxvR9DMjryhvTGHeswO5rUgc7O=QgzzhSJVtiA@mail.gmail.com>
References: <1467838563.1841715.658859833.71EBA624@webmail.messagingengine.com>
	<CAD+L2cyJiRqaPxQWLOOV70Y9=iO2pOSmtP9yF0o1Nm1o7473Sg@mail.gmail.com>
	<1467893312.2860667.659437769.60E835FB@webmail.messagingengine.com>
	<0CE130E9-7415-487F-8B09-DEF39FF26E69@redhat.com>
	<1467894431.2864946.659446681.084918DC@webmail.messagingengine.com>
	<CAD+L2cxmZ0pBaxvR9DMjryhvTGHeswO5rUgc7O=QgzzhSJVtiA@mail.gmail.com>
Message-ID: <1467986222.2381594.660609737.56C1F981@webmail.messagingengine.com>

Thanks!

I entered two issues, 

https://issues.jboss.org/browse/UNDERTOW-769 for cancelling messages and
https://issues.jboss.org/browse/UNDERTOW-768 which is what occurred that
is having me implement some flow control.

-pete

-- 
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

On Thu, Jul 7, 2016, at 07:25 PM, Stuart Douglas wrote:
> Cancellation might be possible to implement, however obviosly once the
> message has actually started sending it will no longer be possible to
> cancel.
> 
> If you create a JIRA I will look into it.
> 
> Stuart
> 
> On Thu, Jul 7, 2016 at 10:27 PM, peter royal <peter.royal at pobox.com>
> wrote:
> > The flush method on *FrameSinkChannel channels? I could use that to see
> > if a message had been sent, but how might that be incorporated into a
> > back pressure algorithm?
> >
> > At my application level I have the notion of a 'topic' that a WS message
> > is sent on. For most topics only the most recent message is the one that
> > matters. For those topics I was going to use the WebSocketCallback to
> > only allow one at a time to be queued on the WebSocketChannel.
> >
> > -pete
> >
> > --
> > (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> >
> > On Thu, Jul 7, 2016, at 07:13 AM, Jason T. Greene wrote:
> >> There is also a flush method on the channel if it's helpful.
> >>
> >> > On Jul 7, 2016, at 7:10 AM, peter royal <peter.royal at pobox.com> wrote:
> >> >
> >> > I looked some more and cancellation would be a huge change - I'm going
> >> > to see how far I can get by using the existing callback for flow
> >> > control.
> >> >
> >> > -pete
> >> >
> >> > --
> >> > (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> >> >
> >> >> On Wed, Jul 6, 2016, at 09:43 PM, Stuart Douglas wrote:
> >> >> Some of the methods take a WebSocketCallback that will notify you on
> >> >> completion or error, however at the moment there is no way to cancel a
> >> >> message.
> >> >>
> >> >> Stuart
> >> >>
> >> >> On Thu, Jul 7, 2016 at 6:56 AM, peter royal <peter.royal at pobox.com>
> >> >> wrote:
> >> >>> I am finding that sometimes I have WebSocket connections that are unable
> >> >>> to flush messages out the socket at the rate I am generating messages.
> >> >>>
> >> >>> I'm using the core.WebSockets class to send messages. Is it possible to
> >> >>> achieve this with what exists currently? My initial guess is no..
> >> >>> conceptually it would be nice for core.WebSockets to return a
> >> >>> CompletableFuture-style object that would let me get a callback when the
> >> >>> message is sent, or have the ability to cancel it if it is still sitting
> >> >>> in the send queue.
> >> >>>
> >> >>> I'm happy to help build something into Undertow if it is a welcome
> >> >>> addition.
> >> >>>
> >> >>> -pete
> >> >>>
> >> >>> --
> >> >>> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
> >> >>> _______________________________________________
> >> >>> 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 z29ding at uwaterloo.ca  Fri Jul  8 11:59:52 2016
From: z29ding at uwaterloo.ca (Jack Ding)
Date: Fri, 8 Jul 2016 11:59:52 -0400
Subject: [undertow-dev] Top level access to servlet request
Message-ID: <CAF49q9_o+71kTCc1yzoGX_1aRmD+Bj3mT+NCk0A1CDxm0fHrAg@mail.gmail.com>

Hi,

Is there a method or workaround that would allow the the initial level
Handler (e.g., PathHandler) for an undertow server access
HttpServletRequest and HttpServletResponse? I am trying to switch our
server from Embedded Jetty, in which the initial handler does some
processing using the HttpServletRequest and Response before matching and
delegating to the appropriate ServletContextHandler, however in Undertow it
seems these are not created (via ServletRequestContext) until after the
matching.


Thank you,


Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160708/970d0c43/attachment.html 

From sdouglas at redhat.com  Sun Jul 10 20:03:58 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 11 Jul 2016 10:03:58 +1000
Subject: [undertow-dev] Top level access to servlet request
In-Reply-To: <CAF49q9_o+71kTCc1yzoGX_1aRmD+Bj3mT+NCk0A1CDxm0fHrAg@mail.gmail.com>
References: <CAF49q9_o+71kTCc1yzoGX_1aRmD+Bj3mT+NCk0A1CDxm0fHrAg@mail.gmail.com>
Message-ID: <CAD+L2cxqx5b325=3xg4EnQVdzc1VBopJ6S3ZOoZri6BTQNHe6A@mail.gmail.com>

No, in Undertow these are not created until the request has actually
been delegated to a Servlet context (as it is possible for requests to
not be using Servlet at all).

What are you trying to do? There is probably a way to do it using
native Undertow handlers.

Stuart

On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding at uwaterloo.ca> wrote:
> Hi,
>
> Is there a method or workaround that would allow the the initial level
> Handler (e.g., PathHandler) for an undertow server access HttpServletRequest
> and HttpServletResponse? I am trying to switch our server from Embedded
> Jetty, in which the initial handler does some processing using the
> HttpServletRequest and Response before matching and delegating to the
> appropriate ServletContextHandler, however in Undertow it seems these are
> not created (via ServletRequestContext) until after the matching.
>
>
> Thank you,
>
>
> Jack
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From z29ding at uwaterloo.ca  Mon Jul 11 10:50:10 2016
From: z29ding at uwaterloo.ca (Jack Ding)
Date: Mon, 11 Jul 2016 10:50:10 -0400
Subject: [undertow-dev] Top level access to servlet request
In-Reply-To: <CAD+L2cxqx5b325=3xg4EnQVdzc1VBopJ6S3ZOoZri6BTQNHe6A@mail.gmail.com>
References: <CAF49q9_o+71kTCc1yzoGX_1aRmD+Bj3mT+NCk0A1CDxm0fHrAg@mail.gmail.com>
	<CAD+L2cxqx5b325=3xg4EnQVdzc1VBopJ6S3ZOoZri6BTQNHe6A@mail.gmail.com>
Message-ID: <CAF49q9-ROAGbaxSBBmohp7oL-djeCT=+CysHHBDWr8ogx9ESwQ@mail.gmail.com>

Hi Stuart,

Thank you for your response. We have a filter class at the top level
currently which authenticates and tracks requests and may decide to delay a
request using AsyncContext's timeout. When implemented at the top level
before being delegated to a servlet, the asynccontext.dispatch will cause
the request (after the delay) to come back through the same filter class.
If it is done after being delegated, the dispatch will directly access the
resource requested. The class will mostly work in the same way if added as
an outer handler to the servlet context, except that dispatch will directly
go to the  underlying resource.

Thanks,
Jack

On Sun, Jul 10, 2016 at 8:03 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> No, in Undertow these are not created until the request has actually
> been delegated to a Servlet context (as it is possible for requests to
> not be using Servlet at all).
>
> What are you trying to do? There is probably a way to do it using
> native Undertow handlers.
>
> Stuart
>
> On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding at uwaterloo.ca> wrote:
> > Hi,
> >
> > Is there a method or workaround that would allow the the initial level
> > Handler (e.g., PathHandler) for an undertow server access
> HttpServletRequest
> > and HttpServletResponse? I am trying to switch our server from Embedded
> > Jetty, in which the initial handler does some processing using the
> > HttpServletRequest and Response before matching and delegating to the
> > appropriate ServletContextHandler, however in Undertow it seems these are
> > not created (via ServletRequestContext) until after the matching.
> >
> >
> > Thank you,
> >
> >
> > Jack
> >
> >
> > _______________________________________________
> > 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/20160711/d4396785/attachment.html 

From ecki at zusammenkunft.net  Mon Jul 11 14:06:09 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 11 Jul 2016 20:06:09 +0200
Subject: [undertow-dev] Top level access to servlet request
In-Reply-To: <CAF49q9-ROAGbaxSBBmohp7oL-djeCT=+CysHHBDWr8ogx9ESwQ@mail.gmail.com>
References: <CAF49q9_o+71kTCc1yzoGX_1aRmD+Bj3mT+NCk0A1CDxm0fHrAg@mail.gmail.com>
	<CAD+L2cxqx5b325=3xg4EnQVdzc1VBopJ6S3ZOoZri6BTQNHe6A@mail.gmail.com>
	<CAF49q9-ROAGbaxSBBmohp7oL-djeCT=+CysHHBDWr8ogx9ESwQ@mail.gmail.com>
Message-ID: <20160711200609.000074d3.ecki@zusammenkunft.net>

Hello,

not directly a answer to your question (doing it in handlers will work,
it is just not very porable) but a comment (if I understood your plan
correctly):

Delaying (failed? flooded?) requests might look like a good thing to do
for security but it only allows attackers to overflow your servers more
easily. Quick closing of connections is a better idea - and in case of
password attempts adding the IP dynamically to a (local) blacklist.

Because even when you have a powerful async server like undertow the
resource consumption of an open tcp socket is enormous (compared to an
attacker with a stateless attack tool or ddos pool).

Gruss
Bernd


 Am Mon, 11 Jul 2016 10:50:10 -0400
schrieb Jack Ding <z29ding at uwaterloo.ca>:

> Hi Stuart,
> 
> Thank you for your response. We have a filter class at the top level
> currently which authenticates and tracks requests and may decide to
> delay a request using AsyncContext's timeout. When implemented at the
> top level before being delegated to a servlet, the
> asynccontext.dispatch will cause the request (after the delay) to
> come back through the same filter class. If it is done after being
> delegated, the dispatch will directly access the resource requested.
> The class will mostly work in the same way if added as an outer
> handler to the servlet context, except that dispatch will directly go
> to the  underlying resource.
> 
> Thanks,
> Jack
> 
> On Sun, Jul 10, 2016 at 8:03 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> 
> > No, in Undertow these are not created until the request has actually
> > been delegated to a Servlet context (as it is possible for requests
> > to not be using Servlet at all).
> >
> > What are you trying to do? There is probably a way to do it using
> > native Undertow handlers.
> >
> > Stuart
> >
> > On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding at uwaterloo.ca>
> > wrote:
> > > Hi,
> > >
> > > Is there a method or workaround that would allow the the initial
> > > level Handler (e.g., PathHandler) for an undertow server access
> > HttpServletRequest
> > > and HttpServletResponse? I am trying to switch our server from
> > > Embedded Jetty, in which the initial handler does some processing
> > > using the HttpServletRequest and Response before matching and
> > > delegating to the appropriate ServletContextHandler, however in
> > > Undertow it seems these are not created (via
> > > ServletRequestContext) until after the matching.
> > >
> > >
> > > Thank you,
> > >
> > >
> > > Jack
> > >
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 

From sdouglas at redhat.com  Mon Jul 11 17:47:54 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 12 Jul 2016 07:47:54 +1000
Subject: [undertow-dev] Top level access to servlet request
In-Reply-To: <20160711200609.000074d3.ecki@zusammenkunft.net>
References: <CAF49q9_o+71kTCc1yzoGX_1aRmD+Bj3mT+NCk0A1CDxm0fHrAg@mail.gmail.com>
	<CAD+L2cxqx5b325=3xg4EnQVdzc1VBopJ6S3ZOoZri6BTQNHe6A@mail.gmail.com>
	<CAF49q9-ROAGbaxSBBmohp7oL-djeCT=+CysHHBDWr8ogx9ESwQ@mail.gmail.com>
	<20160711200609.000074d3.ecki@zusammenkunft.net>
Message-ID: <CAD+L2cyFObkH_xzk1ywb=U2CYhtL8X7v5k4JkceWOAwyGo3dNQ@mail.gmail.com>

While I agree with Bernd that this is not necessarily the best
approach you can also implement this in Undertow quite easily,
something like:

public class DelayHandler implements HttpHandler {

    @Override
    public void handleRequest(HttpServerExchange exchange) throws Exception {
        boolean delay = doStuff();
        if(delay) {
            exchange.getIoThread().executeAfter(new Runnable() {
                @Override
                public void run() {
                    exchange.dispatch(DelayHandler.this);
                }
            }, 30, TimeUnit.SECONDS);
            exchange.dispatch();
            return;
        }
        next.handleRequest();
    }
}

Stuart


On Tue, Jul 12, 2016 at 4:06 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> Hello,
>
> not directly a answer to your question (doing it in handlers will work,
> it is just not very porable) but a comment (if I understood your plan
> correctly):
>
> Delaying (failed? flooded?) requests might look like a good thing to do
> for security but it only allows attackers to overflow your servers more
> easily. Quick closing of connections is a better idea - and in case of
> password attempts adding the IP dynamically to a (local) blacklist.
>
> Because even when you have a powerful async server like undertow the
> resource consumption of an open tcp socket is enormous (compared to an
> attacker with a stateless attack tool or ddos pool).
>
> Gruss
> Bernd
>
>
>  Am Mon, 11 Jul 2016 10:50:10 -0400
> schrieb Jack Ding <z29ding at uwaterloo.ca>:
>
>> Hi Stuart,
>>
>> Thank you for your response. We have a filter class at the top level
>> currently which authenticates and tracks requests and may decide to
>> delay a request using AsyncContext's timeout. When implemented at the
>> top level before being delegated to a servlet, the
>> asynccontext.dispatch will cause the request (after the delay) to
>> come back through the same filter class. If it is done after being
>> delegated, the dispatch will directly access the resource requested.
>> The class will mostly work in the same way if added as an outer
>> handler to the servlet context, except that dispatch will directly go
>> to the  underlying resource.
>>
>> Thanks,
>> Jack
>>
>> On Sun, Jul 10, 2016 at 8:03 PM, Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>
>> > No, in Undertow these are not created until the request has actually
>> > been delegated to a Servlet context (as it is possible for requests
>> > to not be using Servlet at all).
>> >
>> > What are you trying to do? There is probably a way to do it using
>> > native Undertow handlers.
>> >
>> > Stuart
>> >
>> > On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding at uwaterloo.ca>
>> > wrote:
>> > > Hi,
>> > >
>> > > Is there a method or workaround that would allow the the initial
>> > > level Handler (e.g., PathHandler) for an undertow server access
>> > HttpServletRequest
>> > > and HttpServletResponse? I am trying to switch our server from
>> > > Embedded Jetty, in which the initial handler does some processing
>> > > using the HttpServletRequest and Response before matching and
>> > > delegating to the appropriate ServletContextHandler, however in
>> > > Undertow it seems these are not created (via
>> > > ServletRequestContext) until after the matching.
>> > >
>> > >
>> > > Thank you,
>> > >
>> > >
>> > > Jack
>> > >
>> > >
>> > > _______________________________________________
>> > > 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 electrotype at gmail.com  Thu Jul 21 14:06:48 2016
From: electrotype at gmail.com (electrotype)
Date: Thu, 21 Jul 2016 14:06:48 -0400
Subject: [undertow-dev] Problem using two PathHandlers
Message-ID: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>

Hi,

I'm using Undertow 1.2.12.Final (for its Java 7 compatibility).

Let's says I have an /exact /path "/aaa/bbb" for which I want to chain two handlers managed by two 
PathHandlers:

- a SecurityInitialHandler
- a ResourceHandler

In other words, the "/aaa/bbb" exact path is a static resource and is protected.

The problem I found is that if the first PathHandler (the one for the SecurityInitialHandler) 
matches, then this code is called, in io.undertow.server.handlers.PathHandler#handleRequest(...) :

/exchange.setRelativePath(match.getRemaining());/

The "/aaa/bbb" path fully matches so the exchange's relativePath is set to "" after that match.

Then, the seconds PathHandler (the one for ResourceHandler) is run. The matching is done using:

/match = pathMatcher.match(exchange.getRelativePath());/

Since the relative path is now "", and not "/aaa/bbb", the ResourceHandler for "/aaa/bbb" is not 
used, even if it exists.

Worst, since the relative path is now "", the path to match will actually be converted to "/". This 
is because of io.undertow.util.PathMatcher#getExactPath(...) :

/return exactPathMatches.get(URLUtils.normalizeSlashes(path));/

The /normalizeSlashes(path)/ method convert "" to "/".

This means that the /default handler/ of the second PathHandler will be used for "/aaa/bbb". If the 
"/" static resource exists, it will be served instead of the "/aaa/bbb" resource.

Maybe I'm missing something about PathHandlers though... Any tips?

Thanks!

Julien



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160721/84e35ce8/attachment.html 

From tomaz.cerar at gmail.com  Thu Jul 21 19:13:07 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 22 Jul 2016 01:13:07 +0200
Subject: [undertow-dev] Problem using two PathHandlers
In-Reply-To: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
References: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
Message-ID: <CAMquZP5Bx69PgA9TOYd5ad9DpeUkTbv44Ecqg0=eTt9kxpXknw@mail.gmail.com>

On Thu, Jul 21, 2016 at 8:06 PM, electrotype <electrotype at gmail.com> wrote:

> I'm using Undertow 1.2.12.Final (for its Java 7 compatibility).


1.3.x is also java7 compatible. So better use that.

Can you show us the code that sets up handler chain for your server?
That way it will be easier to help.

-
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160722/82d249a7/attachment.html 

From electrotype at gmail.com  Thu Jul 21 19:41:20 2016
From: electrotype at gmail.com (electrotype)
Date: Thu, 21 Jul 2016 19:41:20 -0400
Subject: [undertow-dev] Problem using two PathHandlers
In-Reply-To: <CAMquZP5Bx69PgA9TOYd5ad9DpeUkTbv44Ecqg0=eTt9kxpXknw@mail.gmail.com>
References: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
	<CAMquZP5Bx69PgA9TOYd5ad9DpeUkTbv44Ecqg0=eTt9kxpXknw@mail.gmail.com>
Message-ID: <3e7a6b50-de22-11a0-a4ad-dab4ce7ff367@gmail.com>

Wow, I was 100% sure 1.3.X was for Java 8+ only!! I even added a comment in one of my pom.xml :

/We currently use version 1.2.X because//
//1.3.X requires Java 8./

I must be crazy!! Anyway, that's good news for me.

You can have a look at my actual code here:
https://github.com/spincast/spincast-framework/blob/master/spincast-plugins/spincast-plugins-undertow-parent/spincast-plugins-undertow/src/main/java/org/spincast/plugins/undertow/SpincastUndertowServer.java

The "getFinalHandler()" method returns the first handler of the chain.

But It would probably be easier if I would provide a small example to show my specific issue... I'll 
do that, as soon as possible.

Thanks for your help Tomaz!

Julien

On 2016-07-21 19:13, Toma? Cerar wrote:
>
> On Thu, Jul 21, 2016 at 8:06 PM, electrotype <electrotype at gmail.com 
> <mailto:electrotype at gmail.com>> wrote:
>
>     I'm using Undertow 1.2.12.Final (for its Java 7 compatibility).
>
>
> 1.3.x is also java7 compatible. So better use that.
>
> Can you show us the code that sets up handler chain for your server?
> That way it will be easier to help.
>
> -
> tomaz
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160721/66b46a0f/attachment.html 

From electrotype at gmail.com  Thu Jul 21 20:59:16 2016
From: electrotype at gmail.com (electrotype)
Date: Thu, 21 Jul 2016 20:59:16 -0400
Subject: [undertow-dev] Problem using two PathHandlers
In-Reply-To: <CAMquZP5Bx69PgA9TOYd5ad9DpeUkTbv44Ecqg0=eTt9kxpXknw@mail.gmail.com>
References: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
	<CAMquZP5Bx69PgA9TOYd5ad9DpeUkTbv44Ecqg0=eTt9kxpXknw@mail.gmail.com>
Message-ID: <73bb55f8-b899-59d5-3e92-cda7c372d3f2@gmail.com>

Here's small example (Maven project) :

https://github.com/electrotype/undertow-issue-1

Run the main method and call : http://localhost:44444/aaa/bbb

I would expect this in the console:

------------------------
Handler1
Handler2
------------------------

But I get:

------------------------
Handler1
Default Handler
------------------------

Julien


On 2016-07-21 19:13, Toma? Cerar wrote:
>
> On Thu, Jul 21, 2016 at 8:06 PM, electrotype <electrotype at gmail.com 
> <mailto:electrotype at gmail.com>> wrote:
>
>     I'm using Undertow 1.2.12.Final (for its Java 7 compatibility).
>
>
> 1.3.x is also java7 compatible. So better use that.
>
> Can you show us the code that sets up handler chain for your server?
> That way it will be easier to help.
>
> -
> tomaz
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160721/0b4bd0a5/attachment.html 

From sdouglas at redhat.com  Thu Jul 21 21:14:52 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 22 Jul 2016 11:14:52 +1000
Subject: [undertow-dev] Problem using two PathHandlers
In-Reply-To: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
References: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
Message-ID: <CAD+L2cwwd38JPQ5F5U+Dz+aDd0gPvMCW6n_uZNfg2R8d5Uki-Q@mail.gmail.com>

This is by design, as it allows later handlers to only deal with the
relative path (e.g. if you have files mounted under /files they do not
need to somehow know where they have been mounted, the handler just
deals with the relative path.

It sounds like you want the security handler to use a different type
of handler, maybe something like PredicateHandler (if there is only
one path you care about security wise), or you may want to use
io.undertow.util.PathMatcher to implement your own handler.

Stuart

On Fri, Jul 22, 2016 at 4:06 AM, electrotype <electrotype at gmail.com> wrote:
> Hi,
>
> I'm using Undertow 1.2.12.Final (for its Java 7 compatibility).
>
> Let's says I have an exact path "/aaa/bbb" for which I want to chain two
> handlers managed by two PathHandlers:
>
> - a SecurityInitialHandler
> - a ResourceHandler
>
> In other words, the "/aaa/bbb" exact path is a static resource and is
> protected.
>
> The problem I found is that if the first PathHandler (the one for the
> SecurityInitialHandler) matches, then this code is called, in
> io.undertow.server.handlers.PathHandler#handleRequest(...) :
>
> exchange.setRelativePath(match.getRemaining());
>
> The "/aaa/bbb" path fully matches so the exchange's relativePath is set to
> "" after that match.
>
> Then, the seconds PathHandler (the one for ResourceHandler) is run. The
> matching is done using:
>
> match = pathMatcher.match(exchange.getRelativePath());
>
> Since the relative path is now "", and not "/aaa/bbb", the ResourceHandler
> for "/aaa/bbb" is not used, even if it exists.
>
> Worst, since the relative path is now "", the path to match will actually be
> converted to "/". This is because of
> io.undertow.util.PathMatcher#getExactPath(...) :
>
> return exactPathMatches.get(URLUtils.normalizeSlashes(path));
>
> The normalizeSlashes(path) method convert "" to "/".
>
> This means that the default handler of the second PathHandler will be used
> for "/aaa/bbb". If the "/" static resource exists, it will be served instead
> of the "/aaa/bbb" resource.
>
> Maybe I'm missing something about PathHandlers though... Any tips?
>
> Thanks!
>
> Julien
>
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From electrotype at gmail.com  Fri Jul 22 07:38:43 2016
From: electrotype at gmail.com (electrotype)
Date: Fri, 22 Jul 2016 07:38:43 -0400
Subject: [undertow-dev] Problem using two PathHandlers
In-Reply-To: <CAD+L2cwwd38JPQ5F5U+Dz+aDd0gPvMCW6n_uZNfg2R8d5Uki-Q@mail.gmail.com>
References: <ba43408b-9756-d7a9-3419-ab09f6b46005@gmail.com>
	<CAD+L2cwwd38JPQ5F5U+Dz+aDd0gPvMCW6n_uZNfg2R8d5Uki-Q@mail.gmail.com>
Message-ID: <832452f7-8111-55f5-ce68-e80bcfe0e0d2@gmail.com>

I understand the use case you explain and why PathHandlers behave like that!

I do have a couple of workarounds in mind to fix the issue on my side... But the easiest/cleanest 
would be if PathHandlers had an option to "remove matching path or not". This option could be /true/ 
by default. That way, PathMatchers could also be used to chain handlers that are not related together.

Julien


On 2016-07-21 21:14, Stuart Douglas wrote:
> This is by design, as it allows later handlers to only deal with the
> relative path (e.g. if you have files mounted under /files they do not
> need to somehow know where they have been mounted, the handler just
> deals with the relative path.
>
> It sounds like you want the security handler to use a different type
> of handler, maybe something like PredicateHandler (if there is only
> one path you care about security wise), or you may want to use
> io.undertow.util.PathMatcher to implement your own handler.
>
> Stuart
>
> On Fri, Jul 22, 2016 at 4:06 AM, electrotype <electrotype at gmail.com> wrote:
>> Hi,
>>
>> I'm using Undertow 1.2.12.Final (for its Java 7 compatibility).
>>
>> Let's says I have an exact path "/aaa/bbb" for which I want to chain two
>> handlers managed by two PathHandlers:
>>
>> - a SecurityInitialHandler
>> - a ResourceHandler
>>
>> In other words, the "/aaa/bbb" exact path is a static resource and is
>> protected.
>>
>> The problem I found is that if the first PathHandler (the one for the
>> SecurityInitialHandler) matches, then this code is called, in
>> io.undertow.server.handlers.PathHandler#handleRequest(...) :
>>
>> exchange.setRelativePath(match.getRemaining());
>>
>> The "/aaa/bbb" path fully matches so the exchange's relativePath is set to
>> "" after that match.
>>
>> Then, the seconds PathHandler (the one for ResourceHandler) is run. The
>> matching is done using:
>>
>> match = pathMatcher.match(exchange.getRelativePath());
>>
>> Since the relative path is now "", and not "/aaa/bbb", the ResourceHandler
>> for "/aaa/bbb" is not used, even if it exists.
>>
>> Worst, since the relative path is now "", the path to match will actually be
>> converted to "/". This is because of
>> io.undertow.util.PathMatcher#getExactPath(...) :
>>
>> return exactPathMatches.get(URLUtils.normalizeSlashes(path));
>>
>> The normalizeSlashes(path) method convert "" to "/".
>>
>> This means that the default handler of the second PathHandler will be used
>> for "/aaa/bbb". If the "/" static resource exists, it will be served instead
>> of the "/aaa/bbb" resource.
>>
>> Maybe I'm missing something about PathHandlers though... Any tips?
>>
>> Thanks!
>>
>> Julien
>>
>>
>>
>>
>> _______________________________________________
>> 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/20160722/d04f9995/attachment.html 

From david.robison at psgglobal.net  Mon Jul 25 09:22:38 2016
From: david.robison at psgglobal.net (David Robison)
Date: Mon, 25 Jul 2016 13:22:38 +0000
Subject: [undertow-dev] Question regarding max-post-size
Message-ID: <CY1PR1201MB0921C07F2B54F9B30D1235D2F00D0@CY1PR1201MB0921.namprd12.prod.outlook.com>

I have created a REST interface that receives a continuous stream of JPEGs from a video decoder for the purpose of writing then to a disk file.  The service is defined as:

@POST
@Consumes("*/*")
@Path("/Receive/{videoId}")
public Response receiveVideo(@PathParam("videoId") String videoId, InputStream content)

Everything works fine up until it reaches the max-post-size and then the connection is terminated. Is there any way to disable the max-post-size when streaming video to a REST interface?

Thanks, David

David R Robison
Senior Systems Engineer
O. +1 512 247 3700
M. +1 757 286 0022
david.robison at psgglobal.net<mailto:david.robison at psgglobal.net>
www.psgglobal.net<http://www.psgglobal.net/>

Prometheus Security Group Global, Inc.
3019 Alvin Devane Boulevard
Building 4, Suite 450
Austin, TX 78741


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160725/eed1dd9a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 247 bytes
Desc: image001.png
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160725/eed1dd9a/attachment.png 

From sdouglas at redhat.com  Mon Jul 25 17:41:40 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 26 Jul 2016 07:41:40 +1000
Subject: [undertow-dev] Question regarding max-post-size
In-Reply-To: <CY1PR1201MB0921C07F2B54F9B30D1235D2F00D0@CY1PR1201MB0921.namprd12.prod.outlook.com>
References: <CY1PR1201MB0921C07F2B54F9B30D1235D2F00D0@CY1PR1201MB0921.namprd12.prod.outlook.com>
Message-ID: <CAD+L2cwrEPbCJ_RQQteiQxDOUL1E_WOaNKsXpc1TvBRjmfOnTA@mail.gmail.com>

You need to use io.undertow.server.HttpServerExchange#setMaxEntitySize
(just set it to zero). This has to be done before you start reading from
the stream.

If you are using Servlet and need to get hold of the current exchange you
can use

io.undertow.servlet.handlers.ServletRequestContext.requireCurrent().getExchange()

Stuart



On Mon, Jul 25, 2016 at 11:22 PM, David Robison <david.robison at psgglobal.net
> wrote:

> I have created a REST interface that receives a continuous stream of JPEGs
> from a video decoder for the purpose of writing then to a disk file.  The
> service is defined as:
>
>
>
> @POST
>
> @Consumes("*/*")
>
> @Path("/Receive/{videoId}")
>
> *public* Response receiveVideo(@PathParam("videoId") String videoId,
> InputStream content)
>
>
>
> Everything works fine up until it reaches the max-post-size and then the
> connection is terminated. Is there any way to disable the max-post-size
> when streaming video to a REST interface?
>
>
>
> Thanks, David
>
>
>
> *David R Robison*
>
> *Senior Systems Engineer*
>
> O. +1 512 247 3700
>
> M. +1 757 286 0022
>
> david.robison at psgglobal.net
>
> *www.psgglobal.net <http://www.psgglobal.net/>*
>
> [image: cid:image003.png at 01D19182.F24CA3E0]
>
> *Prometheus Security Group Global, Inc.*
>
> 3019 Alvin Devane Boulevard
>
> Building 4, Suite 450
>
> Austin, TX 78741
>
> [image: cid:image003.png at 01D19182.F24CA3E0]
>
>
>
> _______________________________________________
> 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/20160726/be59e1db/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 247 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160726/be59e1db/attachment-0001.png