From melghaouat at gmail.com  Tue Dec  8 13:06:57 2015
From: melghaouat at gmail.com (Mohammed ElGhaouat)
Date: Tue, 8 Dec 2015 19:06:57 +0100
Subject: [undertow-dev] Resizing undertow thread pool size dynamically
In-Reply-To: <660287892.33618073.1445285965479.JavaMail.zimbra@redhat.com>
References: <CAHP_SgBfzHtCoP5V2bTAgh_Q5ZLyGn+XS274Qud4m26ZCYMMwQ@mail.gmail.com>
	<E330700E-E2AC-4B00-80A5-E4448D6DD9CA@redhat.com>
	<CAHP_SgBOSWUGEGt+M84P7QP6=EGSU0DsNCyT2_fcCXaEeZvJWw@mail.gmail.com>
	<779237744.346643.1439369723927.JavaMail.zimbra@redhat.com>
	<CAHP_SgCu4-7Zev4pc_78PAxFrLNd4fOTLmCcS2M-wt7MJO7EDg@mail.gmail.com>
	<CAHP_SgD9iveAi3S+jhDhxSdLyet4qb9rAuDK3tFOoZoft4B5DA@mail.gmail.com>
	<1485621145.32986999.1445086861898.JavaMail.zimbra@redhat.com>
	<CAHP_SgCJnSkkRBX_L2S8A71npY4dZ6VHsK5YWwZm7hvj7qzUOA@mail.gmail.com>
	<660287892.33618073.1445285965479.JavaMail.zimbra@redhat.com>
Message-ID: <CAHP_SgBzkfEtu0r7V=--qe7JRfdw-Mydn9LjFabbCCwO4WtsZA@mail.gmail.com>

Hello,

this doesn't work for me. I dug a little bit in undertow code and it seems
to me that the *deploymentInfo.executor *we set in the ServletExtension is
not used by *DeploymentImpl *class, the *DeploymentImpl.getExecutor* returns
the field *executor*

 @Override
    public Executor getExecutor() {
       return executor;
    }

while in the constructor we have

 public DeploymentImpl(DeploymentManager deploymentManager, final
DeploymentInfo deploymentInfo, ServletContainer servletContainer) {
     ............
       * this.executor = deploymentInfo.getExecutor();*
     ............
    }

when i changed the getExecutor method to


@Override
    public Executor getExecutor() {
        return deploymentInfo.getExecutor();
    }

I got my executor that I set in the ServletExtension used by Wildfly.

Is this explanation seems right to you ?


Thanks

Mohammed.

On Mon, Oct 19, 2015 at 10:19 PM, Stuart Douglas <sdouglas at redhat.com>
wrote:

>
>
> ----- Original Message -----
> > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: "Jason Greene" <jason.greene at redhat.com>,
> undertow-dev at lists.jboss.org
> > Sent: Tuesday, 20 October, 2015 2:22:58 AM
> > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> dynamically
> >
> > Is this valid for Wildfly? (I am using 8.2.1)
>
> Yes, this is valid for all Servlet deployments, in both Wildfly and
> embedded Undertow.
>
> Wildfly will still create its worker thread pool, but it should not get
> used for this deployment.
>
> Stuart
>
> >
> > From the previous replies, I understood that the ServletExtension could
> be
> > used for embedded Undertow not for Wildfly. Anyway, I gave it a try, but
> > still having Wildfly using task-max-threads and io-threads parameters
> from
> > (subsystem=io/worker=default/).
> >
> > To test this solution, I created a simple wepapp with one simple Servlet
> > and my ServletExtension.handleDeployment is executed by the Wildfly.
> >
> >
> > Thanks
> >
> > On Sat, Oct 17, 2015 at 3:01 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >
> > > Like I said, you can use any thread pool you want if you modify it
> using a
> > > ServletExtension.
> > >
> > > Code looks like:
> > >
> > >
> > > public class MyExtension implements ServletExtension {
> > >
> > >     @Override
> > >     public void handleDeployment(DeploymentInfo deploymentInfo,
> > > ServletContext servletContext) {
> > >        Executor myThreadPool = {my thread pool};
> > >        deploymentInfo.setExecutor(myThreadPool);
> > >     }
> > > }
> > >
> > > Then add a META-INF/services entry for the extension.
> > >
> > > Stuart
> > >
> > > ----- Original Message -----
> > > > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > Cc: "Jason Greene" <jason.greene at redhat.com>,
> > > undertow-dev at lists.jboss.org
> > > > Sent: Wednesday, 14 October, 2015 12:22:20 PM
> > > > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> > > dynamically
> > > >
> > > > Hello,
> > > >
> > > > I would like to share with you some more details about our
> situation. We
> > > > are using some big machines that are shared by many software(many
> Wildfly
> > > > instances, Databases, ERPs ..) If i don't set pools sizes i end up
> with
> > > big
> > > > pools as the default size is dependent on the number of CPU cores
> and out
> > > >  system administrator is complaining about the OS spending time
> checking
> > > if
> > > > the threads have something to do and this impact the other softwares
> > > > installed on the same machine. If I set a small pool size which could
> > > > sufficient in the 90% of time, i am afraid that  Wildfly couldn't
> handle
> > > > the 10% of time when the applications are used by a large number of
> user.
> > > >
> > > > Is there any workaround or are you planning to let the user to set a
> > > > specific ThreadPoolExecutor ? so we can evict idle threads
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Mohammed.
> > > >
> > > >
> > > > On Wed, Aug 12, 2015 at 11:03 AM, Mohammed ElGhaouat <
> > > melghaouat at gmail.com>
> > > > wrote:
> > > >
> > > > > I am using Wildfly.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mohammed.
> > > > >
> > > > > On Wed, Aug 12, 2015 at 10:55 AM, Stuart Douglas <
> sdouglas at redhat.com>
> > > > > wrote:
> > > > >
> > > > >> Are you using Wildfly or embedded Undertow?
> > > > >>
> > > > >> If it is the later you can just use
> > > > >> io.undertow.servlet.api.DeploymentInfo#setExecutor to use whatever
> > > > >> executor
> > > > >> implementation you want.
> > > > >>
> > > > >> The reason why most executors don't reduce the number is because
> > > there is
> > > > >> generally very little point, a parked thread is generally very
> cheap,
> > > > >> while
> > > > >> creating new threads is relatively expensive.
> > > > >>
> > > > >> Stuart
> > > > >>
> > > > >> ----- Original Message -----
> > > > >> > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > > > >> > To: "Jason Greene" <jason.greene at redhat.com>
> > > > >> > Cc: undertow-dev at lists.jboss.org
> > > > >> > Sent: Wednesday, 12 August, 2015 6:19:11 PM
> > > > >> > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> > > > >> dynamically
> > > > >> >
> > > > >> > We are using the servlet API and I am referring to worker pool.
> > > Simply
> > > > >> we
> > > > >> > don't want keeping bunch of idle threads in the JVM consuming
> some
> > > > >> resources
> > > > >> > without doing any thing useful.
> > > > >> >
> > > > >> > So with the bounded queue executor, when the value of the
> > > > >> task-max-threads
> > > > >> > parameter is reached, the number of threads in the worker pool
> > > couldn't
> > > > >> be
> > > > >> > decreased ?
> > > > >> >
> > > > >> > Thank you.
> > > > >> >
> > > > >> >
> > > > >> > Mohammed.
> > > > >> >
> > > > >> > On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene <
> > > jason.greene at redhat.com
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat <
> > > > >> melghaouat at gmail.com >
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > I would like to know if there is a way to make undertow
> reducing
> > > the
> > > > >> size
> > > > >> > > of the thread pool when the server is less loaded. Is there
> any
> > > > >> > > parameter(or other way) that make an idle thread die after
> some
> > > > >> inactivity
> > > > >> > > time ?
> > > > >> >
> > > > >> >
> > > > >> > Are you referring to the worker pool or the I/O pool? The I/O
> pool
> > > is
> > > > >> special
> > > > >> > and is fixed. The worker pool currently uses a JDK
> > > ThreadPoolExecutor
> > > > >> with
> > > > >> > an unbounded queue which is a behavior pattern typically desired
> > > for web
> > > > >> > servers. That?s not pluggable at the moment, but it could be
> > > possible.
> > > > >> >
> > > > >> > If you are using the HttpHandler APIs, there is a method on
> > > > >> > HttpServerDispatch that allows you to use your own custom
> executor
> > > for
> > > > >> > blocking tasks (which would allow you to tune the default worker
> > > task
> > > > >> pool
> > > > >> > very small). If you are using servlet APIs though that uses the
> > > standard
> > > > >> > pools we provide.
> > > > >> >
> > > > >> > Is there a particular reason you want to kill idle threads?
> Threads
> > > are
> > > > >> cheap
> > > > >> > unless you are storing massive amounts of thread local data.
> > > > >> >
> > > > >> > --
> > > > >> > Jason T. Greene
> > > > >> > WildFly Lead / JBoss EAP Platform Architect
> > > > >> > JBoss, a division of Red Hat
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > _______________________________________________
> > > > >> > undertow-dev mailing list
> > > > >> > undertow-dev at lists.jboss.org
> > > > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151208/f031f49a/attachment-0001.html 

From sdouglas at redhat.com  Tue Dec  8 20:33:39 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 8 Dec 2015 20:33:39 -0500 (EST)
Subject: [undertow-dev] Resizing undertow thread pool size dynamically
In-Reply-To: <CAHP_SgBzkfEtu0r7V=--qe7JRfdw-Mydn9LjFabbCCwO4WtsZA@mail.gmail.com>
References: <CAHP_SgBfzHtCoP5V2bTAgh_Q5ZLyGn+XS274Qud4m26ZCYMMwQ@mail.gmail.com>
	<779237744.346643.1439369723927.JavaMail.zimbra@redhat.com>
	<CAHP_SgCu4-7Zev4pc_78PAxFrLNd4fOTLmCcS2M-wt7MJO7EDg@mail.gmail.com>
	<CAHP_SgD9iveAi3S+jhDhxSdLyet4qb9rAuDK3tFOoZoft4B5DA@mail.gmail.com>
	<1485621145.32986999.1445086861898.JavaMail.zimbra@redhat.com>
	<CAHP_SgCJnSkkRBX_L2S8A71npY4dZ6VHsK5YWwZm7hvj7qzUOA@mail.gmail.com>
	<660287892.33618073.1445285965479.JavaMail.zimbra@redhat.com>
	<CAHP_SgBzkfEtu0r7V=--qe7JRfdw-Mydn9LjFabbCCwO4WtsZA@mail.gmail.com>
Message-ID: <1122156407.24813306.1449624819672.JavaMail.zimbra@redhat.com>

Fixed: https://issues.jboss.org/browse/UNDERTOW-593

Stuart

----- Original Message -----
> From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>, "Jason Greene" <jason.greene at redhat.com>, undertow-dev at lists.jboss.org
> Sent: Wednesday, 9 December, 2015 3:06:57 AM
> Subject: Re: [undertow-dev] Resizing undertow thread pool size dynamically
> 
> Hello,
> 
> this doesn't work for me. I dug a little bit in undertow code and it seems
> to me that the *deploymentInfo.executor *we set in the ServletExtension is
> not used by *DeploymentImpl *class, the *DeploymentImpl.getExecutor* returns
> the field *executor*
> 
>  @Override
>     public Executor getExecutor() {
>        return executor;
>     }
> 
> while in the constructor we have
> 
>  public DeploymentImpl(DeploymentManager deploymentManager, final
> DeploymentInfo deploymentInfo, ServletContainer servletContainer) {
>      ............
>        * this.executor = deploymentInfo.getExecutor();*
>      ............
>     }
> 
> when i changed the getExecutor method to
> 
> 
> @Override
>     public Executor getExecutor() {
>         return deploymentInfo.getExecutor();
>     }
> 
> I got my executor that I set in the ServletExtension used by Wildfly.
> 
> Is this explanation seems right to you ?
> 
> 
> Thanks
> 
> Mohammed.
> 
> On Mon, Oct 19, 2015 at 10:19 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > Cc: "Jason Greene" <jason.greene at redhat.com>,
> > undertow-dev at lists.jboss.org
> > > Sent: Tuesday, 20 October, 2015 2:22:58 AM
> > > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> > dynamically
> > >
> > > Is this valid for Wildfly? (I am using 8.2.1)
> >
> > Yes, this is valid for all Servlet deployments, in both Wildfly and
> > embedded Undertow.
> >
> > Wildfly will still create its worker thread pool, but it should not get
> > used for this deployment.
> >
> > Stuart
> >
> > >
> > > From the previous replies, I understood that the ServletExtension could
> > be
> > > used for embedded Undertow not for Wildfly. Anyway, I gave it a try, but
> > > still having Wildfly using task-max-threads and io-threads parameters
> > from
> > > (subsystem=io/worker=default/).
> > >
> > > To test this solution, I created a simple wepapp with one simple Servlet
> > > and my ServletExtension.handleDeployment is executed by the Wildfly.
> > >
> > >
> > > Thanks
> > >
> > > On Sat, Oct 17, 2015 at 3:01 PM, Stuart Douglas <sdouglas at redhat.com>
> > wrote:
> > >
> > > > Like I said, you can use any thread pool you want if you modify it
> > using a
> > > > ServletExtension.
> > > >
> > > > Code looks like:
> > > >
> > > >
> > > > public class MyExtension implements ServletExtension {
> > > >
> > > >     @Override
> > > >     public void handleDeployment(DeploymentInfo deploymentInfo,
> > > > ServletContext servletContext) {
> > > >        Executor myThreadPool = {my thread pool};
> > > >        deploymentInfo.setExecutor(myThreadPool);
> > > >     }
> > > > }
> > > >
> > > > Then add a META-INF/services entry for the extension.
> > > >
> > > > Stuart
> > > >
> > > > ----- Original Message -----
> > > > > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > Cc: "Jason Greene" <jason.greene at redhat.com>,
> > > > undertow-dev at lists.jboss.org
> > > > > Sent: Wednesday, 14 October, 2015 12:22:20 PM
> > > > > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> > > > dynamically
> > > > >
> > > > > Hello,
> > > > >
> > > > > I would like to share with you some more details about our
> > situation. We
> > > > > are using some big machines that are shared by many software(many
> > Wildfly
> > > > > instances, Databases, ERPs ..) If i don't set pools sizes i end up
> > with
> > > > big
> > > > > pools as the default size is dependent on the number of CPU cores
> > and out
> > > > >  system administrator is complaining about the OS spending time
> > checking
> > > > if
> > > > > the threads have something to do and this impact the other softwares
> > > > > installed on the same machine. If I set a small pool size which could
> > > > > sufficient in the 90% of time, i am afraid that  Wildfly couldn't
> > handle
> > > > > the 10% of time when the applications are used by a large number of
> > user.
> > > > >
> > > > > Is there any workaround or are you planning to let the user to set a
> > > > > specific ThreadPoolExecutor ? so we can evict idle threads
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mohammed.
> > > > >
> > > > >
> > > > > On Wed, Aug 12, 2015 at 11:03 AM, Mohammed ElGhaouat <
> > > > melghaouat at gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I am using Wildfly.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Mohammed.
> > > > > >
> > > > > > On Wed, Aug 12, 2015 at 10:55 AM, Stuart Douglas <
> > sdouglas at redhat.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Are you using Wildfly or embedded Undertow?
> > > > > >>
> > > > > >> If it is the later you can just use
> > > > > >> io.undertow.servlet.api.DeploymentInfo#setExecutor to use whatever
> > > > > >> executor
> > > > > >> implementation you want.
> > > > > >>
> > > > > >> The reason why most executors don't reduce the number is because
> > > > there is
> > > > > >> generally very little point, a parked thread is generally very
> > cheap,
> > > > > >> while
> > > > > >> creating new threads is relatively expensive.
> > > > > >>
> > > > > >> Stuart
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >> > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > > > > >> > To: "Jason Greene" <jason.greene at redhat.com>
> > > > > >> > Cc: undertow-dev at lists.jboss.org
> > > > > >> > Sent: Wednesday, 12 August, 2015 6:19:11 PM
> > > > > >> > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> > > > > >> dynamically
> > > > > >> >
> > > > > >> > We are using the servlet API and I am referring to worker pool.
> > > > Simply
> > > > > >> we
> > > > > >> > don't want keeping bunch of idle threads in the JVM consuming
> > some
> > > > > >> resources
> > > > > >> > without doing any thing useful.
> > > > > >> >
> > > > > >> > So with the bounded queue executor, when the value of the
> > > > > >> task-max-threads
> > > > > >> > parameter is reached, the number of threads in the worker pool
> > > > couldn't
> > > > > >> be
> > > > > >> > decreased ?
> > > > > >> >
> > > > > >> > Thank you.
> > > > > >> >
> > > > > >> >
> > > > > >> > Mohammed.
> > > > > >> >
> > > > > >> > On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene <
> > > > jason.greene at redhat.com
> > > > > >> >
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat <
> > > > > >> melghaouat at gmail.com >
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > Hi,
> > > > > >> > >
> > > > > >> > > I would like to know if there is a way to make undertow
> > reducing
> > > > the
> > > > > >> size
> > > > > >> > > of the thread pool when the server is less loaded. Is there
> > any
> > > > > >> > > parameter(or other way) that make an idle thread die after
> > some
> > > > > >> inactivity
> > > > > >> > > time ?
> > > > > >> >
> > > > > >> >
> > > > > >> > Are you referring to the worker pool or the I/O pool? The I/O
> > pool
> > > > is
> > > > > >> special
> > > > > >> > and is fixed. The worker pool currently uses a JDK
> > > > ThreadPoolExecutor
> > > > > >> with
> > > > > >> > an unbounded queue which is a behavior pattern typically desired
> > > > for web
> > > > > >> > servers. That?s not pluggable at the moment, but it could be
> > > > possible.
> > > > > >> >
> > > > > >> > If you are using the HttpHandler APIs, there is a method on
> > > > > >> > HttpServerDispatch that allows you to use your own custom
> > executor
> > > > for
> > > > > >> > blocking tasks (which would allow you to tune the default worker
> > > > task
> > > > > >> pool
> > > > > >> > very small). If you are using servlet APIs though that uses the
> > > > standard
> > > > > >> > pools we provide.
> > > > > >> >
> > > > > >> > Is there a particular reason you want to kill idle threads?
> > Threads
> > > > are
> > > > > >> cheap
> > > > > >> > unless you are storing massive amounts of thread local data.
> > > > > >> >
> > > > > >> > --
> > > > > >> > Jason T. Greene
> > > > > >> > WildFly Lead / JBoss EAP Platform Architect
> > > > > >> > JBoss, a division of Red Hat
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > _______________________________________________
> > > > > >> > undertow-dev mailing list
> > > > > >> > undertow-dev at lists.jboss.org
> > > > > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 


From kid at bitkid.com  Thu Dec 10 07:22:38 2015
From: kid at bitkid.com (Sascha Sadat-Guscheh)
Date: Thu, 10 Dec 2015 13:22:38 +0100
Subject: [undertow-dev] how to use futures with undertow?
Message-ID: <0606B593-7594-46C6-9584-9E75533BE8CE@bitkid.com>

Hi!

We want to use undertow as the http server for our application. Our current API is based on futures (java8 completable futures). My question is how do i combine futures with the concept of handlers. My rather naive implementation would be something like that.

class MyHandler implements HttpHandler {
        @Override
        public void handleRequest(HttpServerExchange exchange) throws Exception {
            exchange.getRequestReceiver().receiveFullString((exchange1, message) -> {
                CompletableFuture<Response> responseFuture = doTheWork(message);
                exchange1.dispatch();
                responseFuture.whenCompleteAsync((response, throwable) -> {
                     exchange1.getResponseSender().send(response);
                });
            });
        }
}

does this look reasonable? responseFuture.whenCompleteAsync() can be passed an Executor. Should i use an Executor from the HttpServerExchange for that? actually i tried to, but it?s always null. Another way would be:

class MyHandler implements HttpHandler {
        @Override
        public void handleRequest(HttpServerExchange exchange) throws Exception {
            exchange.getRequestReceiver().receiveFullString((exchange1, message) -> {
                CompletableFuture<Response> responseFuture = doTheWork(message);
                exchange1.dispatch(() -> {
                        exchange1.getResponseSender().send(responseFuture.get());
                });
            });
        }
}

What?s the correct way to do it?

Thanks, Sascha 

From sdouglas at redhat.com  Sun Dec 13 20:32:09 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 13 Dec 2015 20:32:09 -0500 (EST)
Subject: [undertow-dev] how to use futures with undertow?
In-Reply-To: <0606B593-7594-46C6-9584-9E75533BE8CE@bitkid.com>
References: <0606B593-7594-46C6-9584-9E75533BE8CE@bitkid.com>
Message-ID: <1473170942.26359456.1450056729693.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sascha Sadat-Guscheh" <kid at bitkid.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 10 December, 2015 9:22:38 PM
> Subject: [undertow-dev] how to use futures with undertow?
> 
> Hi!
> 
> We want to use undertow as the http server for our application. Our current
> API is based on futures (java8 completable futures). My question is how do i
> combine futures with the concept of handlers. My rather naive implementation
> would be something like that.
> 
> class MyHandler implements HttpHandler {
>         @Override
>         public void handleRequest(HttpServerExchange exchange) throws
>         Exception {
>             exchange.getRequestReceiver().receiveFullString((exchange1,
>             message) -> {
>                 CompletableFuture<Response> responseFuture =
>                 doTheWork(message);
>                 exchange1.dispatch();
>                 responseFuture.whenCompleteAsync((response, throwable) -> {
>                      exchange1.getResponseSender().send(response);
>                 });
>             });
>         }
> }

This looks reasonable. If you want to use an Executor you can use either:

exchange.getIoThread() (to execute in the IO thread, this should be fine for you example)
exchange.getConnection.getWorker() (to execute blocking tasks)

Stuart

> 
> does this look reasonable? responseFuture.whenCompleteAsync() can be passed
> an Executor. Should i use an Executor from the HttpServerExchange for that?
> actually i tried to, but it?s always null. Another way would be:
> 
> class MyHandler implements HttpHandler {
>         @Override
>         public void handleRequest(HttpServerExchange exchange) throws
>         Exception {
>             exchange.getRequestReceiver().receiveFullString((exchange1,
>             message) -> {
>                 CompletableFuture<Response> responseFuture =
>                 doTheWork(message);
>                 exchange1.dispatch(() -> {
>                         exchange1.getResponseSender().send(responseFuture.get());
>                 });
>             });
>         }
> }

This will block the thread until the future is ready, the 

> 
> What?s the correct way to do it?
> 
> Thanks, Sascha
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From kid at bitkid.com  Tue Dec 15 07:11:12 2015
From: kid at bitkid.com (Sascha Sadat-Guscheh)
Date: Tue, 15 Dec 2015 13:11:12 +0100
Subject: [undertow-dev] how to use futures with undertow?
In-Reply-To: <1473170942.26359456.1450056729693.JavaMail.zimbra@redhat.com>
References: <0606B593-7594-46C6-9584-9E75533BE8CE@bitkid.com>
	<1473170942.26359456.1450056729693.JavaMail.zimbra@redhat.com>
Message-ID: <6C2EBB18-2BB1-4B68-99CB-F4739C3EE830@bitkid.com>

Hi Stuart!

Thanks for your response. I already figured that the idea to wait for the future is probably not the best one ;-)

> exchange.getIoThread()

that was what i was looking for.

Merci, Sascha

> On 14 Dec 2015, at 02:32, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Sascha Sadat-Guscheh" <kid at bitkid.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Thursday, 10 December, 2015 9:22:38 PM
>> Subject: [undertow-dev] how to use futures with undertow?
>> 
>> Hi!
>> 
>> We want to use undertow as the http server for our application. Our current
>> API is based on futures (java8 completable futures). My question is how do i
>> combine futures with the concept of handlers. My rather naive implementation
>> would be something like that.
>> 
>> class MyHandler implements HttpHandler {
>>        @Override
>>        public void handleRequest(HttpServerExchange exchange) throws
>>        Exception {
>>            exchange.getRequestReceiver().receiveFullString((exchange1,
>>            message) -> {
>>                CompletableFuture<Response> responseFuture =
>>                doTheWork(message);
>>                exchange1.dispatch();
>>                responseFuture.whenCompleteAsync((response, throwable) -> {
>>                     exchange1.getResponseSender().send(response);
>>                });
>>            });
>>        }
>> }
> 
> This looks reasonable. If you want to use an Executor you can use either:
> 
> exchange.getIoThread() (to execute in the IO thread, this should be fine for you example)
> exchange.getConnection.getWorker() (to execute blocking tasks)
> 
> Stuart
> 
>> 
>> does this look reasonable? responseFuture.whenCompleteAsync() can be passed
>> an Executor. Should i use an Executor from the HttpServerExchange for that?
>> actually i tried to, but it?s always null. Another way would be:
>> 
>> class MyHandler implements HttpHandler {
>>        @Override
>>        public void handleRequest(HttpServerExchange exchange) throws
>>        Exception {
>>            exchange.getRequestReceiver().receiveFullString((exchange1,
>>            message) -> {
>>                CompletableFuture<Response> responseFuture =
>>                doTheWork(message);
>>                exchange1.dispatch(() -> {
>>                        exchange1.getResponseSender().send(responseFuture.get());
>>                });
>>            });
>>        }
>> }
> 
> This will block the thread until the future is ready, the 
> 
>> 
>> What?s the correct way to do it?
>> 
>> Thanks, Sascha
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/undertow-dev <https://lists.jboss.org/mailman/listinfo/undertow-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151215/6580109f/attachment-0001.html 

From kid at bitkid.com  Mon Dec 21 11:22:18 2015
From: kid at bitkid.com (Sascha Sadat-Guscheh)
Date: Mon, 21 Dec 2015 17:22:18 +0100
Subject: [undertow-dev] Undertow configuration
Message-ID: <4BC034BF-78FD-4CC4-810D-3E2A9CA88B28@bitkid.com>

Hi!

We want to use undertow in the following scenario (numbers are from our current app running jetty as a front end):

- 24 core machine with ~60GB ram
- 10000 requests per second with an average execution time of 2-4 ms
- around 6000 concurrent http connections (keep-alive)
- incoming request size between 2000 and 4000 bytes
- response size around 4000 bytes

At the moment we just copied the configuration from the Undertow class (using a HttpOpenListener).

OptionMap socketOptions = OptionMap.builder()
        .set(Options.WORKER_IO_THREADS, IO_THREADS)
        .set(Options.TCP_NODELAY, true)
        .set(Options.REUSE_ADDRESSES, true)
        .set(Options.BALANCING_TOKENS, 1)
        .set(Options.BALANCING_CONNECTIONS, 2)
        .set(Options.BACKLOG, 1000)
        .getMap();

OptionMap undertowOptions = OptionMap.builder().set(UndertowOptions.BUFFER_PIPELINED_DATA, true).getMap();
ByteBufferPool buffers = new DefaultByteBufferPool(true, 1024 * 16, -1, 4);
HttpOpenListener openListener = new HttpOpenListener(buffers, undertowOptions);

worker = xnio.createWorker(OptionMap.builder()
	        .set(Options.WORKER_IO_THREADS, IO_THREADS)
	        .set(Options.CONNECTION_HIGH_WATER, 1000000)
	        .set(Options.CONNECTION_LOW_WATER, 1000000)
	        .set(Options.WORKER_TASK_CORE_THREADS, IO_THREADS * 8)
	        .set(Options.WORKER_TASK_MAX_THREADS, IO_THREADS * 8)
	        .set(Options.TCP_NODELAY, true)
	        .set(Options.CORK, true)
	        .getMap());

Some of the options i don?t understand fully (BALANCING_TOKENS, BALANCING_CONNECTIONS) some may not be applicable to our scenario.
I dug around in the code a bit to find out what these settings do but i don?t feel very confident. A little help would be appreciated! 

Enjoy your holidays, Sascha



From sdouglas at redhat.com  Tue Dec 22 01:27:37 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 22 Dec 2015 01:27:37 -0500 (EST)
Subject: [undertow-dev] Undertow configuration
In-Reply-To: <4BC034BF-78FD-4CC4-810D-3E2A9CA88B28@bitkid.com>
References: <4BC034BF-78FD-4CC4-810D-3E2A9CA88B28@bitkid.com>
Message-ID: <620094799.1299884.1450765657654.JavaMail.zimbra@redhat.com>

BALANCING_TOKENS and BALANCING_CONNECTIONS were a way of ensuring that connections get evenly distributed to IO threads. Newer XNIO releases (3.3.3.Final and above) don't actually use them any more, and they will be ignored (instead hashing is used to ensure an even distribution).

Stuart



----- Original Message -----
> From: "Sascha Sadat-Guscheh" <kid at bitkid.com>
> To: undertow-dev at lists.jboss.org
> Sent: Tuesday, 22 December, 2015 1:22:18 AM
> Subject: [undertow-dev] Undertow configuration
> 
> Hi!
> 
> We want to use undertow in the following scenario (numbers are from our
> current app running jetty as a front end):
> 
> - 24 core machine with ~60GB ram
> - 10000 requests per second with an average execution time of 2-4 ms
> - around 6000 concurrent http connections (keep-alive)
> - incoming request size between 2000 and 4000 bytes
> - response size around 4000 bytes
> 
> At the moment we just copied the configuration from the Undertow class (using
> a HttpOpenListener).
> 
> OptionMap socketOptions = OptionMap.builder()
>         .set(Options.WORKER_IO_THREADS, IO_THREADS)
>         .set(Options.TCP_NODELAY, true)
>         .set(Options.REUSE_ADDRESSES, true)
>         .set(Options.BALANCING_TOKENS, 1)
>         .set(Options.BALANCING_CONNECTIONS, 2)
>         .set(Options.BACKLOG, 1000)
>         .getMap();
> 
> OptionMap undertowOptions =
> OptionMap.builder().set(UndertowOptions.BUFFER_PIPELINED_DATA,
> true).getMap();
> ByteBufferPool buffers = new DefaultByteBufferPool(true, 1024 * 16, -1, 4);
> HttpOpenListener openListener = new HttpOpenListener(buffers,
> undertowOptions);
> 
> worker = xnio.createWorker(OptionMap.builder()
> 	        .set(Options.WORKER_IO_THREADS, IO_THREADS)
> 	        .set(Options.CONNECTION_HIGH_WATER, 1000000)
> 	        .set(Options.CONNECTION_LOW_WATER, 1000000)
> 	        .set(Options.WORKER_TASK_CORE_THREADS, IO_THREADS * 8)
> 	        .set(Options.WORKER_TASK_MAX_THREADS, IO_THREADS * 8)
> 	        .set(Options.TCP_NODELAY, true)
> 	        .set(Options.CORK, true)
> 	        .getMap());
> 
> Some of the options i don?t understand fully (BALANCING_TOKENS,
> BALANCING_CONNECTIONS) some may not be applicable to our scenario.
> I dug around in the code a bit to find out what these settings do but i don?t
> feel very confident. A little help would be appreciated!
> 
> Enjoy your holidays, Sascha
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From arjan.tijms at gmail.com  Wed Dec 23 09:24:57 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 23 Dec 2015 15:24:57 +0100
Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
Message-ID: <CAE=-AhAxEh-bdG41iH=X4B+AdJX8qSzvi+ELGheUS=j2AE5jUA@mail.gmail.com>

Hi,

I wonder if it would make sense to port the (small) fix for UNDERTOW-577
back to Undertow 1.3.x, and hopefully still include this with WF 10 final.

This concerns one of the last (known) larger bugs with JASPIC in WildFly.
Without this being fixed, something like the 403 or 404 from a SAM is not
possible, Returning a 403 is specifically needed for the BASIC scheme.

For instance, the following JSR 375 authentication mechanism now works on
GlassFish, but throws a "UT010019: Response already commited" on WildFly
10rc4/Undertow 1.3.11:

public AuthStatus validateRequest(HttpServletRequest request,
HttpServletResponse response, HttpMsgContext httpMsgContext) throws
AuthException {
String[] credentials = getCredentials(request);
if (!isEmpty(credentials)) {

   IdentityStore identityStore =
CDI.current().select(IdentityStore.class).get();

   CredentialValidationResult result = identityStore.validate(
                new UsernamePasswordCredential(credentials[0], new
Password(credentials[1])));

            if (result.getStatus() == VALID) {
                return httpMsgContext.notifyContainerAboutLogin(
                    result.getCallerName(), result.getCallerGroups());
}
}
if (httpMsgContext.isProtected()) {
response.setHeader("WWW-Authenticate", basicHeaderValue);
return httpMsgContext.responseUnAuthorized();
}
return httpMsgContext.doNothing();
}

The problem is the "httpMsgContext.responseUnAuthorized();" which does:

     try {
getResponse().sendError(SC_UNAUTHORIZED);
} catch (IOException e) {
throw new IllegalStateException(e);
}

    return SEND_FAILURE;

I'm not really sure what the schedule is for Undertow 1.4 vs a potential WF
11 and/or EAP 7. If WF 11 is still far away and EAP 7 will be based on WF
10, then it would really be great if this small but rather important fix
could still be included in WF 10.

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151223/be19b1b3/attachment.html 

From sdouglas at redhat.com  Wed Dec 23 20:00:36 2015
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 23 Dec 2015 20:00:36 -0500 (EST)
Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
In-Reply-To: <CAE=-AhAxEh-bdG41iH=X4B+AdJX8qSzvi+ELGheUS=j2AE5jUA@mail.gmail.com>
References: <CAE=-AhAxEh-bdG41iH=X4B+AdJX8qSzvi+ELGheUS=j2AE5jUA@mail.gmail.com>
Message-ID: <1364207675.2200437.1450918836903.JavaMail.zimbra@redhat.com>

Looks like I made a mistake in the JIRA, it should already be in Wildfly. Can you test it out?

Stuart

----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "undertow-dev" <undertow-dev at lists.jboss.org>
> Sent: Wednesday, 23 December, 2015 11:24:57 PM
> Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
> 
> Hi,
> 
> I wonder if it would make sense to port the (small) fix for UNDERTOW-577 back
> to Undertow 1.3.x, and hopefully still include this with WF 10 final.
> 
> This concerns one of the last (known) larger bugs with JASPIC in WildFly.
> Without this being fixed, something like the 403 or 404 from a SAM is not
> possible, Returning a 403 is specifically needed for the BASIC scheme.
> 
> For instance, the following JSR 375 authentication mechanism now works on
> GlassFish, but throws a "UT010019: Response already commited" on WildFly
> 10rc4/Undertow 1.3.11:
> 
> public AuthStatus validateRequest(HttpServletRequest request,
> HttpServletResponse response, HttpMsgContext httpMsgContext) throws
> AuthException {
> String[] credentials = getCredentials(request);
> if (!isEmpty(credentials)) {
> IdentityStore identityStore =
> CDI.current().select(IdentityStore.class).get();
> CredentialValidationResult result = identityStore.validate(
> new UsernamePasswordCredential(credentials[0], new
> Password(credentials[1])));
> 
> if (result.getStatus() == VALID) {
> return httpMsgContext.notifyContainerAboutLogin(
> result.getCallerName(), result.getCallerGroups());
> }
> }
> if (httpMsgContext.isProtected()) {
> response.setHeader("WWW-Authenticate", basicHeaderValue);
> return httpMsgContext.responseUnAuthorized();
> }
> return httpMsgContext.doNothing();
> }
> 
> The problem is the "httpMsgContext.responseUnAuthorized();" which does:
> 
> try {
> getResponse().sendError(SC_UNAUTHORIZED);
> } catch (IOException e) {
> throw new IllegalStateException(e);
> }
> return SEND_FAILURE;
> 
> I'm not really sure what the schedule is for Undertow 1.4 vs a potential WF
> 11 and/or EAP 7. If WF 11 is still far away and EAP 7 will be based on WF
> 10, then it would really be great if this small but rather important fix
> could still be included in WF 10.
> 
> Kind regards,
> Arjan Tijms
> 
> 
> 
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From arjan.tijms at gmail.com  Thu Dec 24 02:58:11 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 24 Dec 2015 08:58:11 +0100
Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
In-Reply-To: <1364207675.2200437.1450918836903.JavaMail.zimbra@redhat.com>
References: <CAE=-AhAxEh-bdG41iH=X4B+AdJX8qSzvi+ELGheUS=j2AE5jUA@mail.gmail.com>
	<1364207675.2200437.1450918836903.JavaMail.zimbra@redhat.com>
Message-ID: <CAE=-AhABieHV2xX+O1kOKCjjc9PoP58XzVZyNnLVStZxMKRsEA@mail.gmail.com>

Hi,

On Thu, Dec 24, 2015 at 2:00 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Looks like I made a mistake in the JIRA, it should already be in Wildfly.
> Can you test it out?
>

I did a quick test yesterday with WF10 CR5 (using the above code) and it
still failed. When I manually applied the exact patch to Undertow 1.3..x in
WildFly 10 CR4 a few weeks back it worked. But to be absolutely sure I'll
double check again today. Thanks!

Kind regards,
Arjan Tijms




>
> Stuart
>
> ----- Original Message -----
> > From: "arjan tijms" <arjan.tijms at gmail.com>
> > To: "undertow-dev" <undertow-dev at lists.jboss.org>
> > Sent: Wednesday, 23 December, 2015 11:24:57 PM
> > Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
> >
> > Hi,
> >
> > I wonder if it would make sense to port the (small) fix for UNDERTOW-577
> back
> > to Undertow 1.3.x, and hopefully still include this with WF 10 final.
> >
> > This concerns one of the last (known) larger bugs with JASPIC in WildFly.
> > Without this being fixed, something like the 403 or 404 from a SAM is not
> > possible, Returning a 403 is specifically needed for the BASIC scheme.
> >
> > For instance, the following JSR 375 authentication mechanism now works on
> > GlassFish, but throws a "UT010019: Response already commited" on WildFly
> > 10rc4/Undertow 1.3.11:
> >
> > public AuthStatus validateRequest(HttpServletRequest request,
> > HttpServletResponse response, HttpMsgContext httpMsgContext) throws
> > AuthException {
> > String[] credentials = getCredentials(request);
> > if (!isEmpty(credentials)) {
> > IdentityStore identityStore =
> > CDI.current().select(IdentityStore.class).get();
> > CredentialValidationResult result = identityStore.validate(
> > new UsernamePasswordCredential(credentials[0], new
> > Password(credentials[1])));
> >
> > if (result.getStatus() == VALID) {
> > return httpMsgContext.notifyContainerAboutLogin(
> > result.getCallerName(), result.getCallerGroups());
> > }
> > }
> > if (httpMsgContext.isProtected()) {
> > response.setHeader("WWW-Authenticate", basicHeaderValue);
> > return httpMsgContext.responseUnAuthorized();
> > }
> > return httpMsgContext.doNothing();
> > }
> >
> > The problem is the "httpMsgContext.responseUnAuthorized();" which does:
> >
> > try {
> > getResponse().sendError(SC_UNAUTHORIZED);
> > } catch (IOException e) {
> > throw new IllegalStateException(e);
> > }
> > return SEND_FAILURE;
> >
> > I'm not really sure what the schedule is for Undertow 1.4 vs a potential
> WF
> > 11 and/or EAP 7. If WF 11 is still far away and EAP 7 will be based on WF
> > 10, then it would really be great if this small but rather important fix
> > could still be included in WF 10.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20151224/7f22e4dc/attachment-0001.html 

From arjan.tijms at gmail.com  Thu Dec 24 09:28:23 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 24 Dec 2015 15:28:23 +0100
Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
In-Reply-To: <1364207675.2200437.1450918836903.JavaMail.zimbra@redhat.com>
References: <CAE=-AhAxEh-bdG41iH=X4B+AdJX8qSzvi+ELGheUS=j2AE5jUA@mail.gmail.com>
	<1364207675.2200437.1450918836903.JavaMail.zimbra@redhat.com>
Message-ID: <CAE=-AhDTqRUmPnobMN02srC5iioVqwLEmUvJ5J_rv+tSoRHdKA@mail.gmail.com>

Hi,

On Thu, Dec 24, 2015 at 2:00 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Looks like I made a mistake in the JIRA, it should already be in Wildfly.
> Can you test it out?
>

I just did the check again and lo and behold, the fix is indeed already
there. I'm not really sure what went wrong with my quick test the other day
but it clearly works now. Double checked the source of
undertow-servlet-1.3.11.Final and the fix is really there, so this is
absolutely great. Thanks again!

One question about the commit though, when it was committed here:
https://github.com/undertow-io/undertow/commit/6e9663576fcaaa14f5a9cedf4ae1a144b20fd09e

It was committed in the master, but master was already 1.4.x at Nov 6, or
did I miss something here? Doesn't matter much for the end result but just
curious.

Kind regards,
Arjan Tijms




>
> Stuart
>
> ----- Original Message -----
> > From: "arjan tijms" <arjan.tijms at gmail.com>
> > To: "undertow-dev" <undertow-dev at lists.jboss.org>
> > Sent: Wednesday, 23 December, 2015 11:24:57 PM
> > Subject: [undertow-dev] UNDERTOW-577 - response code from SAM
> >
> > Hi,
> >
> > I wonder if it would make sense to port the (small) fix for UNDERTOW-577
> back
> > to Undertow 1.3.x, and hopefully still include this with WF 10 final.
> >
> > This concerns one of the last (known) larger bugs with JASPIC in WildFly.
> > Without this being fixed, something like the 403 or 404 from a SAM is not
> > possible, Returning a 403 is specifically needed for the BASIC scheme.
> >
> > For instance, the following JSR 375 authentication mechanism now works on
> > GlassFish, but throws a "UT010019: Response already commited" on WildFly
> > 10rc4/Undertow 1.3.11:
> >
> > public AuthStatus validateRequest(HttpServletRequest request,
> > HttpServletResponse response, HttpMsgContext httpMsgContext) throws
> > AuthException {
> > String[] credentials = getCredentials(request);
> > if (!isEmpty(credentials)) {
> > IdentityStore identityStore =
> > CDI.current().select(IdentityStore.class).get();
> > CredentialValidationResult result = identityStore.validate(
> > new UsernamePasswordCredential(credentials[0], new
> > Password(credentials[1])));
> >
> > if (result.getStatus() == VALID) {
> > return httpMsgContext.notifyContainerAboutLogin(
> > result.getCallerName(), result.getCallerGroups());
> > }
> > }
> > if (httpMsgContext.isProtected()) {
> > response.setHeader("WWW-Authenticate", basicHeaderValue);
> > return httpMsgContext.responseUnAuthorized();
> > }
> > return httpMsgContext.doNothing();
> > }
> >
> > The problem is the "httpMsgContext.responseUnAuthorized();" which does:
> >
> > try {
> > getResponse().sendError(SC_UNAUTHORIZED);
> > } catch (IOException e) {
> > throw new IllegalStateException(e);
> > }
> > return SEND_FAILURE;
> >
> > I'm not really sure what the schedule is for Undertow 1.4 vs a potential
> WF
> > 11 and/or EAP 7. If WF 11 is still far away and EAP 7 will be based on WF
> > 10, then it would really be great if this small but rather important fix
> > could still be included in WF 10.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20151224/d3c43d84/attachment.html 

From scrapmachines at gmail.com  Mon Dec 28 08:16:08 2015
From: scrapmachines at gmail.com (Girish Sharma)
Date: Mon, 28 Dec 2015 18:46:08 +0530
Subject: [undertow-dev] Efficient and easy way to set and get thread local
	variables
Message-ID: <CA+tMX4dxhEhrK2kSX9bs8cW-nvZOKczOqyZLrAUiotgL+e+1ag@mail.gmail.com>

Hi all,

I am really impressed by the throughput I am getting using standalone
undertow server using non-blocking IO and what not.

Now, I have a use case where I need to maintain a per call thread level
boolean flag which needs to be accessible from various parts of the code.
This flag is determined by an exchange attribute (say request header).

So the question is whether there is an easy and efficient way to get a
reference to any exchange attribute (or the exchange itself) from anywhere
in the code? I really don't want to rely on thread locals or custom caches
to do this if there is a way to get a reference. Or if Undertow natively
has similar functionality to set and retreive a thread level flags, I'd be
happy to use that too.

PS: I am still going through list archives, but the UI to go through all of
them is really tiresome :)

-- 
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151228/d631753a/attachment.html 

From blue at nqzero.com  Wed Dec 30 01:05:05 2015
From: blue at nqzero.com (seth/nqzero)
Date: Wed, 30 Dec 2015 01:05:05 -0500
Subject: [undertow-dev] embedded undertow async hello world
Message-ID: <CAJtn+AfV5US7rLssY_J7ZyJXj4e+BsCi3qwMmcjw92LW47wOyA@mail.gmail.com>

i'm doing a quick survey of java webserver performance baselines, with a
focus on async, inspired somewhat by the Techempower plaintext benchmark.
i've already done jetty (both sync and async), jetty-comsat (ie quasar),
the kilim (another bytecode based fiber implementation) http server, and
sync undertow (copied from the techempower github impl). i'd like to add an
undertow async

for jetty i've used the servlet api for async, since i didn't see any other
option. but i'd prefer the non-servlet api for undertow. the docs for
undertow seem limited, esp for async. so i wanted to vet my solution. i'm
more interested in being canonical than squeezing the last bit of
performance (because eg: all the solutions are plenty fast, it's a terrible
benchmark, ease of implementation is a bigger factor than absolute
performance)

open to any general comments, but specifically wondering:
- is my use of dispatch() correct
- do i need to be calling isInIoThread()
- is it safe to access the exchange directly in reply() ? ie, in a
non-undertow thread

this is a somewhat simplified example that gets 75-80k req/s vs 85-90 for
the more verbose version, but the use of the async api is the same


____my code is below___

import io.undertow.Handlers;
import io.undertow.Undertow;
import io.undertow.server.HttpHandler;
import io.undertow.server.HttpServerExchange;
import io.undertow.util.Headers;
import java.nio.ByteBuffer;
import java.util.Timer;
import java.util.TimerTask;

public final class UtowAsync implements HttpHandler {

  public static void main(String[] args) throws Exception {
    Undertow.builder()
        .addHttpListener(9097,"0.0.0.0")
        .setHandler(Handlers.path().addPrefixPath("/hello",new UtowAsync()))
        .build()
        .start();
  }

    int num = 0;
    HttpServerExchange acv[] = new HttpServerExchange[10000];
    byte [] bytes = "hello world".getBytes();
    ByteBuffer buf = ByteBuffer.allocate(bytes.length).put(bytes);
    { buf.flip(); }

    synchronized void store(HttpServerExchange async) {
        if (async==null) while (num > 0) {
            reply(acv[--num]);
            acv[num] = null;
        }
        else acv[num++] = async;
    }

    void reply(HttpServerExchange exchange) {
        exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
"text/plain");
        exchange.getResponseSender().send(buf.duplicate());
    }

    public void handleRequest(final HttpServerExchange exchange) throws
Exception {
        store(exchange);
        exchange.dispatch();
    }

    {
        new Timer().schedule(new TimerTask() { public void run() {
            UtowAsync.this.store(null);
        } },10,10);
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151230/25f1cceb/attachment.html