From slavastap at gmail.com  Wed Nov  2 10:00:45 2016
From: slavastap at gmail.com (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkA==?=)
Date: Wed, 2 Nov 2016 17:00:45 +0300
Subject: [undertow-dev] Undertow Read TimeOut Response
Message-ID: <CANO169+bYvYyXSnpwUYJxgFvsbRBq-J55S0DK6a_xOoPEsn84Q@mail.gmail.com>

In our project we use Undertow in WildFly application server.
Also we set Read Time Out limits for Undertow.
As we can understand, Read Time Out managed by
ReadTimeoutStreamSourceConduit class.
At Read Time Out moment will be called IoUtils.safeClose and resources will
be closed.
But we want to return message with TimeOut code (
StatusCodes.REQUEST_TIME_OUT ).
How can we properly close Exchange and return code to client as response?

I tried to handle in exchange.getConnection().addCloseListener , but i cant
find a way to return code.
Also, i found Test
/undertow-core/src/test/java/io/undertow/server/ReadTimeoutTestCase.java,
but it doesnt work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20161102/5b98fadc/attachment.html 

From sdouglas at redhat.com  Wed Nov  2 17:36:21 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 3 Nov 2016 08:36:21 +1100
Subject: [undertow-dev] Undertow Read TimeOut Response
In-Reply-To: <CANO169+bYvYyXSnpwUYJxgFvsbRBq-J55S0DK6a_xOoPEsn84Q@mail.gmail.com>
References: <CANO169+bYvYyXSnpwUYJxgFvsbRBq-J55S0DK6a_xOoPEsn84Q@mail.gmail.com>
Message-ID: <CAD+L2czaRKZ0+9RgiMAxxA4+sdtGiuJ457Ai5aP+V5rwjr8Exw@mail.gmail.com>

In general if there is a read timeout it is because something has gone
wrong with the connection or the client, it is very unlikely that
sending a response will actually succeed, and could just result in a
write timeout.

That is why we just close the connection on read timeout, without
trying to send any sort of response.

Stuart

On Thu, Nov 3, 2016 at 1:00 AM, ???????? ? <slavastap at gmail.com> wrote:
> In our project we use Undertow in WildFly application server.
> Also we set Read Time Out limits for Undertow.
> As we can understand, Read Time Out managed by
> ReadTimeoutStreamSourceConduit class.
> At Read Time Out moment will be called IoUtils.safeClose and resources will
> be closed.
> But we want to return message with TimeOut code (
> StatusCodes.REQUEST_TIME_OUT ).
> How can we properly close Exchange and return code to client as response?
>
> I tried to handle in exchange.getConnection().addCloseListener , but i cant
> find a way to return code.
> Also, i found Test
> /undertow-core/src/test/java/io/undertow/server/ReadTimeoutTestCase.java,
> but it doesnt work.
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From stevehu at gmail.com  Mon Nov  7 18:46:01 2016
From: stevehu at gmail.com (Steve Hu)
Date: Mon, 7 Nov 2016 18:46:01 -0500
Subject: [undertow-dev] GRPC on Undertow
Message-ID: <CAGjN9KV35sLba6D_DQiRDMr4vFyagGVj5VAy8oWVf3+11xemFA@mail.gmail.com>

Hi,

The current GRPC Java is implemented on Netty and I am wondering if you are
interested in implementing another version on Undertow. It would be very
nice so that I can have both REST and GRPC running on Undertow. GRPC is the
future of microservices architecture.

https://github.com/grpc/grpc-java

I have a REST microservices framework built on top of Undertow and planning
to start a GRPC framework.

https://github.com/networknt/light-java

Thanks,

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

From sdouglas at redhat.com  Mon Nov  7 22:35:44 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 8 Nov 2016 14:35:44 +1100
Subject: [undertow-dev] GRPC on Undertow
In-Reply-To: <CAGjN9KV35sLba6D_DQiRDMr4vFyagGVj5VAy8oWVf3+11xemFA@mail.gmail.com>
References: <CAGjN9KV35sLba6D_DQiRDMr4vFyagGVj5VAy8oWVf3+11xemFA@mail.gmail.com>
Message-ID: <CAD+L2cxX81m6mgMhwUf4eMKGApyKzxFsZjj6SVbu67NE5SvarA@mail.gmail.com>

This is definitely something that I would be interested in looking at,
although I am not sure when I will have time.

Stuart

On Tue, Nov 8, 2016 at 10:46 AM, Steve Hu <stevehu at gmail.com> wrote:
> Hi,
>
> The current GRPC Java is implemented on Netty and I am wondering if you are
> interested in implementing another version on Undertow. It would be very
> nice so that I can have both REST and GRPC running on Undertow. GRPC is the
> future of microservices architecture.
>
> https://github.com/grpc/grpc-java
>
> I have a REST microservices framework built on top of Undertow and planning
> to start a GRPC framework.
>
> https://github.com/networknt/light-java
>
> Thanks,
>
> Steve
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From hbraun at redhat.com  Tue Nov  8 14:40:17 2016
From: hbraun at redhat.com (Heiko Braun)
Date: Tue, 8 Nov 2016 20:40:17 +0100
Subject: [undertow-dev] GRPC on Undertow
In-Reply-To: <CAD+L2cxX81m6mgMhwUf4eMKGApyKzxFsZjj6SVbu67NE5SvarA@mail.gmail.com>
References: <CAGjN9KV35sLba6D_DQiRDMr4vFyagGVj5VAy8oWVf3+11xemFA@mail.gmail.com>
	<CAD+L2cxX81m6mgMhwUf4eMKGApyKzxFsZjj6SVbu67NE5SvarA@mail.gmail.com>
Message-ID: <66702843-1E95-4012-A983-1FF22FB70E05@redhat.com>

Same here, i am definitely interested in helping to make that happen. I think it would be good to start an open source effort around that, maybe even under the grpc umbrella or the intention to move it there, so we can all contribute to that.

Regards Heiko



> Am 08.11.2016 um 04:35 schrieb Stuart Douglas <sdouglas at redhat.com>:
> 
> This is definitely something that I would be interested in looking at,
> although I am not sure when I will have time.
> 
> Stuart
> 
>> On Tue, Nov 8, 2016 at 10:46 AM, Steve Hu <stevehu at gmail.com> wrote:
>> Hi,
>> 
>> The current GRPC Java is implemented on Netty and I am wondering if you are
>> interested in implementing another version on Undertow. It would be very
>> nice so that I can have both REST and GRPC running on Undertow. GRPC is the
>> future of microservices architecture.
>> 
>> https://github.com/grpc/grpc-java
>> 
>> I have a REST microservices framework built on top of Undertow and planning
>> to start a GRPC framework.
>> 
>> https://github.com/networknt/light-java
>> 
>> Thanks,
>> 
>> Steve
>> 
>> 
>> _______________________________________________
>> 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 stevehu at gmail.com  Tue Nov  8 20:25:08 2016
From: stevehu at gmail.com (Steve Hu)
Date: Tue, 8 Nov 2016 20:25:08 -0500
Subject: [undertow-dev] GRPC on Undertow
In-Reply-To: <66702843-1E95-4012-A983-1FF22FB70E05@redhat.com>
References: <CAGjN9KV35sLba6D_DQiRDMr4vFyagGVj5VAy8oWVf3+11xemFA@mail.gmail.com>
	<CAD+L2cxX81m6mgMhwUf4eMKGApyKzxFsZjj6SVbu67NE5SvarA@mail.gmail.com>
	<66702843-1E95-4012-A983-1FF22FB70E05@redhat.com>
Message-ID: <CAGjN9KUEyqiU3v9BSsX8jhvosBeVN3UgQOkNrKbsfOoRMPO08w@mail.gmail.com>

Stuart/Braun,

I am glad you are on the same page, the current grpc implementation has a
lot of potential to improve performance and I think Undertow will
definitely a good alternative http server. I have tested myself between
Undertow based Light Java and Netty based Spring Boot and there are big
performance gaps on both throughput and latency. Testing result(first one
Undertow and last one Netty) and source code can be found at

https://github.com/networknt/light-java-example/tree/master/performance

Let me know once you start the project and I will contribute whenever time
permits.

Thanks,

Steve

On Tue, Nov 8, 2016 at 2:40 PM, Heiko Braun <hbraun at redhat.com> wrote:

> Same here, i am definitely interested in helping to make that happen. I
> think it would be good to start an open source effort around that, maybe
> even under the grpc umbrella or the intention to move it there, so we can
> all contribute to that.
>
> Regards Heiko
>
>
>
> > Am 08.11.2016 um 04:35 schrieb Stuart Douglas <sdouglas at redhat.com>:
> >
> > This is definitely something that I would be interested in looking at,
> > although I am not sure when I will have time.
> >
> > Stuart
> >
> >> On Tue, Nov 8, 2016 at 10:46 AM, Steve Hu <stevehu at gmail.com> wrote:
> >> Hi,
> >>
> >> The current GRPC Java is implemented on Netty and I am wondering if you
> are
> >> interested in implementing another version on Undertow. It would be very
> >> nice so that I can have both REST and GRPC running on Undertow. GRPC is
> the
> >> future of microservices architecture.
> >>
> >> https://github.com/grpc/grpc-java
> >>
> >> I have a REST microservices framework built on top of Undertow and
> planning
> >> to start a GRPC framework.
> >>
> >> https://github.com/networknt/light-java
> >>
> >> Thanks,
> >>
> >> Steve
> >>
> >>
> >> _______________________________________________
> >> 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/20161108/b9655f70/attachment.html 

From kr at asseco.dk  Mon Nov 14 05:50:25 2016
From: kr at asseco.dk (Kim Rasmussen)
Date: Mon, 14 Nov 2016 11:50:25 +0100
Subject: [undertow-dev] Request/Response wrappers on HttpServerExchange not
	cleared ?
Message-ID: <CAGX6Y=2BE9=xzfLdj=3EDTvh2gmH10EQ1WM72QfDa0SyU4AN1Q@mail.gmail.com>

Hi,

I am working on a reverse proxy using undertow, and I have just added
debugging support, where I can add a request/response wrapper to the
exchange and save/trace/debug the result.

I noticed that for persistent connections, those wrappers seem to be kept
on the exchange when subsequent requests arrive - even after endExchange()
has been called on the first request.

Can that be true ? Is there something I need to do to cleanup when the
exchange ends ? or should they have been removed in closeAndFlushResponse()
?

-- 
Med venlig hilsen / Best regards

*Kim Rasmussen*
Partner, IT Architect

*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20161114/17f93e5b/attachment-0001.html 

From kr at asseco.dk  Thu Nov 17 10:07:38 2016
From: kr at asseco.dk (Kim Rasmussen)
Date: Thu, 17 Nov 2016 16:07:38 +0100
Subject: [undertow-dev] Request/Response wrappers on HttpServerExchange
	not cleared ?
In-Reply-To: <CAGX6Y=2BE9=xzfLdj=3EDTvh2gmH10EQ1WM72QfDa0SyU4AN1Q@mail.gmail.com>
References: <CAGX6Y=2BE9=xzfLdj=3EDTvh2gmH10EQ1WM72QfDa0SyU4AN1Q@mail.gmail.com>
Message-ID: <CAGX6Y=1sMUvLJyBCFVAv6+cz25qVt_WOiFHEH6x5nTAU49tMFA@mail.gmail.com>

Please disregard the question, I believe it was my own fault.
Sorry.

/Kim

2016-11-14 11:50 GMT+01:00 Kim Rasmussen <kr at asseco.dk>:

> Hi,
>
> I am working on a reverse proxy using undertow, and I have just added
> debugging support, where I can add a request/response wrapper to the
> exchange and save/trace/debug the result.
>
> I noticed that for persistent connections, those wrappers seem to be kept
> on the exchange when subsequent requests arrive - even after endExchange()
> has been called on the first request.
>
> Can that be true ? Is there something I need to do to cleanup when the
> exchange ends ? or should they have been removed in closeAndFlushResponse()
> ?
>
> --
> Med venlig hilsen / Best regards
>
> *Kim Rasmussen*
> Partner, IT Architect
>
> *Asseco Denmark A/S*
> Kronprinsessegade 54
> DK-1306 Copenhagen K
> Mobile: +45 26 16 40 23
> Ph.: +45 33 36 46 60
> Fax: +45 33 36 46 61
>



-- 
Med venlig hilsen / Best regards

*Kim Rasmussen*
Partner, IT Architect

*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20161117/ff0b4bee/attachment.html 

From bill at dartalley.com  Sat Nov 19 16:24:30 2016
From: bill at dartalley.com (Bill O'Neil)
Date: Sat, 19 Nov 2016 16:24:30 -0500
Subject: [undertow-dev] Is there a hook for before sending data to the
	client?
Message-ID: <CANd+gFwFCCnyvC9UpBw6uCs9O20OQ0q5_Cok0DKMMZ7q7ZzETw@mail.gmail.com>

Hello,

I'm trying to make a handler that manages a request scoped sql transaction.
Ideally it would be a middleware handler that opens the connection and
starts the transaction and after the chain of handlers is finished it will
commit the transaction. The issue I am facing is the browser can receive
the data before the transaction is committed since the data is sent further
down the chain.

Is there some type of hook where I can commit / close the transaction
before any data is sent? This should work fine in a blocking handler but an
asynchronous one may have issues?

My other thought is to make a Handler that expects some object to be
returned. In this handler commit / close the connection as soon as the
object is returned then send the data to the browser after. Would this be
my best option?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20161119/15370d63/attachment.html 

From sdouglas at redhat.com  Sun Nov 20 16:23:40 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 21 Nov 2016 08:23:40 +1100
Subject: [undertow-dev] Is there a hook for before sending data to the
	client?
In-Reply-To: <CANd+gFwFCCnyvC9UpBw6uCs9O20OQ0q5_Cok0DKMMZ7q7ZzETw@mail.gmail.com>
References: <CANd+gFwFCCnyvC9UpBw6uCs9O20OQ0q5_Cok0DKMMZ7q7ZzETw@mail.gmail.com>
Message-ID: <CAD+L2cyajdc3+J7m8k4xnZ3JfxZhPu9Jcb61+uW-Sx8+4j6Ffw@mail.gmail.com>

You can use io.undertow.server.HttpServerExchange#addResponseCommitListener
and implement the ResponseCommitListener interface.

Stuart

On Sun, Nov 20, 2016 at 8:24 AM, Bill O'Neil <bill at dartalley.com> wrote:
> Hello,
>
> I'm trying to make a handler that manages a request scoped sql transaction.
> Ideally it would be a middleware handler that opens the connection and
> starts the transaction and after the chain of handlers is finished it will
> commit the transaction. The issue I am facing is the browser can receive the
> data before the transaction is committed since the data is sent further down
> the chain.
>
> Is there some type of hook where I can commit / close the transaction before
> any data is sent? This should work fine in a blocking handler but an
> asynchronous one may have issues?
>
> My other thought is to make a Handler that expects some object to be
> returned. In this handler commit / close the connection as soon as the
> object is returned then send the data to the browser after. Would this be my
> best option?
>
> Thanks,
> Bill
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bill at dartalley.com  Sun Nov 20 16:37:49 2016
From: bill at dartalley.com (Bill O'Neil)
Date: Sun, 20 Nov 2016 16:37:49 -0500
Subject: [undertow-dev] Is there a hook for before sending data to the
	client?
In-Reply-To: <CAD+L2cyajdc3+J7m8k4xnZ3JfxZhPu9Jcb61+uW-Sx8+4j6Ffw@mail.gmail.com>
References: <CANd+gFwFCCnyvC9UpBw6uCs9O20OQ0q5_Cok0DKMMZ7q7ZzETw@mail.gmail.com>
	<CAD+L2cyajdc3+J7m8k4xnZ3JfxZhPu9Jcb61+uW-Sx8+4j6Ffw@mail.gmail.com>
Message-ID: <CANd+gFxmmVpzktBnCi93Kdc_XrhrUy9THudYEeTZ7eW6WS1g3A@mail.gmail.com>

Exactly what I was looking for thanks!

On Sun, Nov 20, 2016 at 4:23 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> You can use io.undertow.server.HttpServerExchange#
> addResponseCommitListener
> and implement the ResponseCommitListener interface.
>
> Stuart
>
> On Sun, Nov 20, 2016 at 8:24 AM, Bill O'Neil <bill at dartalley.com> wrote:
> > Hello,
> >
> > I'm trying to make a handler that manages a request scoped sql
> transaction.
> > Ideally it would be a middleware handler that opens the connection and
> > starts the transaction and after the chain of handlers is finished it
> will
> > commit the transaction. The issue I am facing is the browser can receive
> the
> > data before the transaction is committed since the data is sent further
> down
> > the chain.
> >
> > Is there some type of hook where I can commit / close the transaction
> before
> > any data is sent? This should work fine in a blocking handler but an
> > asynchronous one may have issues?
> >
> > My other thought is to make a Handler that expects some object to be
> > returned. In this handler commit / close the connection as soon as the
> > object is returned then send the data to the browser after. Would this
> be my
> > best option?
> >
> > Thanks,
> > Bill
> >
> > _______________________________________________
> > 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/20161120/19a1369e/attachment.html 

From mike at stardog.com  Mon Nov 21 14:07:56 2016
From: mike at stardog.com (Michael Grove)
Date: Mon, 21 Nov 2016 14:07:56 -0500
Subject: [undertow-dev] is there a server option for max http line length?
Message-ID: <CAKqS+r3mKwRZZGMJ=Vex1GXtoz=_Jye+9CuVf2ozmTMwCbFepA@mail.gmail.com>

I found `UndertowOptions.MAX_HEADER_SIZE` which seemed to roughly
correspond to this, but from what I could see in the HTTP listener,
connections are severed if they exceed the length rather than sending a 414.

Is there a different option I should be using?

Thanks.

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

From sdouglas at redhat.com  Mon Nov 21 20:26:23 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 22 Nov 2016 12:26:23 +1100
Subject: [undertow-dev] is there a server option for max http line
	length?
In-Reply-To: <CAKqS+r3mKwRZZGMJ=Vex1GXtoz=_Jye+9CuVf2ozmTMwCbFepA@mail.gmail.com>
References: <CAKqS+r3mKwRZZGMJ=Vex1GXtoz=_Jye+9CuVf2ozmTMwCbFepA@mail.gmail.com>
Message-ID: <CAD+L2czyuD5QSizd+P3fYk=d0rwyhTKgrZgSQkz_3GrKPXT4RA@mail.gmail.com>

The reason why it kills the connection is to remove the need to
read+discard the rest of the header block.

In normal usage this limit should never be hit, if a client does hit
this then we assume they are trying something malicious so we drop the
connection.

Stuart

On Tue, Nov 22, 2016 at 6:07 AM, Michael Grove <mike at stardog.com> wrote:
> I found `UndertowOptions.MAX_HEADER_SIZE` which seemed to roughly correspond
> to this, but from what I could see in the HTTP listener, connections are
> severed if they exceed the length rather than sending a 414.
>
> Is there a different option I should be using?
>
> Thanks.
>
> Mike
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From oliver at analyticspot.com  Tue Nov 22 15:44:36 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Tue, 22 Nov 2016 20:44:36 +0000
Subject: [undertow-dev] dispatch and isDispatched do not agree
Message-ID: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>

I've got some pretty simple code that looks something like:

if (!exhange.isDispatched()) {
    exchange.dispatch(() -> {
        assert exchange.isDispatched();
         // more stuff....
    });
}

but the assert fails. That is, when dispatch calls my runnable isDispatched
is not true.

I believe I have a bug somewhere with how/when dispatches are happening so
I've littered my code with such asserts and they fail reliably even when
I'm quite sure the exchange has been dispatched (e.g. when it is literally
the first call in a Runnable passed to to the dispatch() method).

What am I doing wrong?
-- 
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/20161122/676faec6/attachment.html 

From sdouglas at redhat.com  Tue Nov 22 15:47:19 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 23 Nov 2016 07:47:19 +1100
Subject: [undertow-dev] dispatch and isDispatched do not agree
In-Reply-To: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
References: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
Message-ID: <CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>

After the call stack returns and the dispatch actually happens
isDispatched() will return false (allowing the exchange to be
dispatched again).

In general you should not really need to check this anyway, if you
want to know if you are in the IO thread you should use isInIiThread()
instead.

Stuart

On Wed, Nov 23, 2016 at 7:44 AM, Oliver Dain <oliver at analyticspot.com> wrote:
> I've got some pretty simple code that looks something like:
>
> if (!exhange.isDispatched()) {
>     exchange.dispatch(() -> {
>         assert exchange.isDispatched();
>          // more stuff....
>     });
> }
>
> but the assert fails. That is, when dispatch calls my runnable isDispatched
> is not true.
>
> I believe I have a bug somewhere with how/when dispatches are happening so
> I've littered my code with such asserts and they fail reliably even when I'm
> quite sure the exchange has been dispatched (e.g. when it is literally the
> first call in a Runnable passed to to the dispatch() method).
>
> What am I doing wrong?
> --
> 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 Nov 22 15:56:47 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Tue, 22 Nov 2016 20:56:47 +0000
Subject: [undertow-dev] dispatch and isDispatched do not agree
In-Reply-To: <CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>
References: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
	<CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>
Message-ID: <CACSC6EW1NopyHxZDr9aA2jKRcEYUZC-VVY37W9mPnKXXHkC3sA@mail.gmail.com>

Wow! Thanks for the super-fast reply.

I think I'm a little confused about the difference between being in an IO
thread and being dispatched. Is it the case that if the server thinks I'm
"not dispatched" (that is, if the server will send a response on my behalf
when my method returns) that I'm always on an IO thread? I often do some
work on my own thread pools and those threads often interact with the
HttpServerExchange object. I know that some interactions with the exchange
object (e.g. recieveFullBytes) will take an exchange that is in a
dispatched state and put it in a non-dispatched state. So I want to just
keep checking that I'm dispatched and, if I'm not, dispatch again. So my
code might look something like:

void handle(HttpServerExchange exchange) {
    exchange.dispatch(myOwnThreadPoolExecutor, () -> {
        log.info("I am not not on an IO thread and I am dispatched.");
        doSomethingWithExchange(exchange);
        assert exchange.isDispatched();
        assert !exchange.isInIoThread();
        // how do I check to see if I'm still in a dispatched state?
    });
}

(note: the above is a bad, super-simplified example and in the actual code
there's a lot of asynchronous stuff happening that bounces the execution
from one thread pool to another).

The reason for all of this is that I have some edge cases which appear to
be race conditions in which I know for sure that I call exchange.dispatch()
and then I start doing some work but the exchange gets ended before I've
finished my computations and have a response to send leaving the client
with an empty response. I'm not entirely sure how that could happen, but my
best guess right now is that I interact with the exchange in some way that
causes it to no longer be in in the dispatched state and, as a result, the
HttpServerExchange is ending the exchange for me before I'm ready.

Thanks again,
Oliver



On Tue, Nov 22, 2016 at 12:47 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> After the call stack returns and the dispatch actually happens
> isDispatched() will return false (allowing the exchange to be
> dispatched again).
>
> In general you should not really need to check this anyway, if you
> want to know if you are in the IO thread you should use isInIiThread()
> instead.
>
> Stuart
>
> On Wed, Nov 23, 2016 at 7:44 AM, Oliver Dain <oliver at analyticspot.com>
> wrote:
> > I've got some pretty simple code that looks something like:
> >
> > if (!exhange.isDispatched()) {
> >     exchange.dispatch(() -> {
> >         assert exchange.isDispatched();
> >          // more stuff....
> >     });
> > }
> >
> > but the assert fails. That is, when dispatch calls my runnable
> isDispatched
> > is not true.
> >
> > I believe I have a bug somewhere with how/when dispatches are happening
> so
> > I've littered my code with such asserts and they fail reliably even when
> I'm
> > quite sure the exchange has been dispatched (e.g. when it is literally
> the
> > first call in a Runnable passed to to the dispatch() method).
> >
> > What am I doing wrong?
> > --
> > CTO, Analytic Spot
> > 44 West Broadway #222
> > Eugene, OR 97401
> > analyticspot.com ? 425-296-6556 <(425)%20296-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/20161122/924f288a/attachment.html 

From sdouglas at redhat.com  Tue Nov 22 16:12:42 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 23 Nov 2016 08:12:42 +1100
Subject: [undertow-dev] dispatch and isDispatched do not agree
In-Reply-To: <CACSC6EW1NopyHxZDr9aA2jKRcEYUZC-VVY37W9mPnKXXHkC3sA@mail.gmail.com>
References: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
	<CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>
	<CACSC6EW1NopyHxZDr9aA2jKRcEYUZC-VVY37W9mPnKXXHkC3sA@mail.gmail.com>
Message-ID: <CAD+L2cyWVC3kE5ZoSjE+bPVJ0zbDv=gO6mOmekpuvnyDCJnx0w@mail.gmail.com>

On Wed, Nov 23, 2016 at 7:56 AM, Oliver Dain <oliver at analyticspot.com> wrote:
> Wow! Thanks for the super-fast reply.
>
> I think I'm a little confused about the difference between being in an IO
> thread and being dispatched. Is it the case that if the server thinks I'm
> "not dispatched" (that is, if the server will send a response on my behalf
> when my method returns) that I'm always on an IO thread? I often do some
> work on my own thread pools and those threads often interact with the
> HttpServerExchange object. I know that some interactions with the exchange
> object (e.g. recieveFullBytes) will take an exchange that is in a dispatched
> state and put it in a non-dispatched state. So I want to just keep checking
> that I'm dispatched and, if I'm not, dispatch again. So my code might look
> something like:
>
> void handle(HttpServerExchange exchange) {
>     exchange.dispatch(myOwnThreadPoolExecutor, () -> {
>         log.info("I am not not on an IO thread and I am dispatched.");
>         doSomethingWithExchange(exchange);
>         assert exchange.isDispatched();
>         assert !exchange.isInIoThread();
>         // how do I check to see if I'm still in a dispatched state?
>     });
> }

So the basic idea behind the 'dispatch' is that it is a way of
guaranteeing thread safety without needing to synchronize the exchange
object. Effectively it allows you to pass an exchange from one thread
to another in a way that guarantees that the first thread is 'done'
with the exchange before the second thread starts.

>
> (note: the above is a bad, super-simplified example and in the actual code
> there's a lot of asynchronous stuff happening that bounces the execution
> from one thread pool to another).
>
> The reason for all of this is that I have some edge cases which appear to be
> race conditions in which I know for sure that I call exchange.dispatch() and
> then I start doing some work but the exchange gets ended before I've
> finished my computations and have a response to send leaving the client with
> an empty response. I'm not entirely sure how that could happen, but my best
> guess right now is that I interact with the exchange in some way that causes
> it to no longer be in in the dispatched state and, as a result, the
> HttpServerExchange is ending the exchange for me before I'm ready.

I think I would need to look at a more specific example of what you
are doing, but it is possibly related to how you are handing stuff in
other threads? The exchange itself is not thread safe, if you start
doing work on the exchange in another thread without having dispatched
you can get a race condition.

Stuart

>
> Thanks again,
> Oliver
>
>
>
> On Tue, Nov 22, 2016 at 12:47 PM Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> After the call stack returns and the dispatch actually happens
>> isDispatched() will return false (allowing the exchange to be
>> dispatched again).
>>
>> In general you should not really need to check this anyway, if you
>> want to know if you are in the IO thread you should use isInIiThread()
>> instead.
>>
>> Stuart
>>
>> On Wed, Nov 23, 2016 at 7:44 AM, Oliver Dain <oliver at analyticspot.com>
>> wrote:
>> > I've got some pretty simple code that looks something like:
>> >
>> > if (!exhange.isDispatched()) {
>> >     exchange.dispatch(() -> {
>> >         assert exchange.isDispatched();
>> >          // more stuff....
>> >     });
>> > }
>> >
>> > but the assert fails. That is, when dispatch calls my runnable
>> > isDispatched
>> > is not true.
>> >
>> > I believe I have a bug somewhere with how/when dispatches are happening
>> > so
>> > I've littered my code with such asserts and they fail reliably even when
>> > I'm
>> > quite sure the exchange has been dispatched (e.g. when it is literally
>> > the
>> > first call in a Runnable passed to to the dispatch() method).
>> >
>> > What am I doing wrong?
>> > --
>> > 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


From oliver at analyticspot.com  Tue Nov 22 16:20:52 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Tue, 22 Nov 2016 21:20:52 +0000
Subject: [undertow-dev] dispatch and isDispatched do not agree
In-Reply-To: <CAD+L2cyWVC3kE5ZoSjE+bPVJ0zbDv=gO6mOmekpuvnyDCJnx0w@mail.gmail.com>
References: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
	<CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>
	<CACSC6EW1NopyHxZDr9aA2jKRcEYUZC-VVY37W9mPnKXXHkC3sA@mail.gmail.com>
	<CAD+L2cyWVC3kE5ZoSjE+bPVJ0zbDv=gO6mOmekpuvnyDCJnx0w@mail.gmail.com>
Message-ID: <CACSC6EUebXFmk85GETbe3+oGirY67d5Gec6nP6E9g8Jz6BnD-g@mail.gmail.com>

Thanks for the clarification. I think I'm OK, but want to double check.

I have some code that will pass an exchange object between thread pools not
owned by Undertow. I can guarantee that I won't interact with the exchange
from more than one thread at at time, but I will move it from thread pool
to thread pool. For example, I might get a request and call dispatch. I'd
then call a function that extracts a header from the exchange and then does
an async lookup in a database for the info that was found in the header.
When the DB lookup is complete I'll get a callback in a thread owned by the
DB. In that callback I might extract another header from the exchange and
then do another async lookup in a different database with a different
thread pool. When that call is complete I'll get a callback in yet another
thread, again not owned by Undertow. In that final callback I'd call
"exchange.getResponseSender().send(...)" to send the final response.

If I guarantee that I'm not operating on the exchange in more than one
thread at a time I shouldn't have to worry about synchronization. However,
since some async HttpServerExchange operations, like receiveFullBytes, can
put me back on the Undertow IO pool I do need to check
"exchange.isInIoThread()" and, if that returns true, I then need to call
dispatch again.

Does that all sound correct?

On Tue, Nov 22, 2016 at 1:12 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> On Wed, Nov 23, 2016 at 7:56 AM, Oliver Dain <oliver at analyticspot.com>
> wrote:
> > Wow! Thanks for the super-fast reply.
> >
> > I think I'm a little confused about the difference between being in an IO
> > thread and being dispatched. Is it the case that if the server thinks I'm
> > "not dispatched" (that is, if the server will send a response on my
> behalf
> > when my method returns) that I'm always on an IO thread? I often do some
> > work on my own thread pools and those threads often interact with the
> > HttpServerExchange object. I know that some interactions with the
> exchange
> > object (e.g. recieveFullBytes) will take an exchange that is in a
> dispatched
> > state and put it in a non-dispatched state. So I want to just keep
> checking
> > that I'm dispatched and, if I'm not, dispatch again. So my code might
> look
> > something like:
> >
> > void handle(HttpServerExchange exchange) {
> >     exchange.dispatch(myOwnThreadPoolExecutor, () -> {
> >         log.info("I am not not on an IO thread and I am dispatched.");
> >         doSomethingWithExchange(exchange);
> >         assert exchange.isDispatched();
> >         assert !exchange.isInIoThread();
> >         // how do I check to see if I'm still in a dispatched state?
> >     });
> > }
>
> So the basic idea behind the 'dispatch' is that it is a way of
> guaranteeing thread safety without needing to synchronize the exchange
> object. Effectively it allows you to pass an exchange from one thread
> to another in a way that guarantees that the first thread is 'done'
> with the exchange before the second thread starts.
>
> >
> > (note: the above is a bad, super-simplified example and in the actual
> code
> > there's a lot of asynchronous stuff happening that bounces the execution
> > from one thread pool to another).
> >
> > The reason for all of this is that I have some edge cases which appear
> to be
> > race conditions in which I know for sure that I call exchange.dispatch()
> and
> > then I start doing some work but the exchange gets ended before I've
> > finished my computations and have a response to send leaving the client
> with
> > an empty response. I'm not entirely sure how that could happen, but my
> best
> > guess right now is that I interact with the exchange in some way that
> causes
> > it to no longer be in in the dispatched state and, as a result, the
> > HttpServerExchange is ending the exchange for me before I'm ready.
>
> I think I would need to look at a more specific example of what you
> are doing, but it is possibly related to how you are handing stuff in
> other threads? The exchange itself is not thread safe, if you start
> doing work on the exchange in another thread without having dispatched
> you can get a race condition.
>
> Stuart
>
> >
> > Thanks again,
> > Oliver
> >
> >
> >
> > On Tue, Nov 22, 2016 at 12:47 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> After the call stack returns and the dispatch actually happens
> >> isDispatched() will return false (allowing the exchange to be
> >> dispatched again).
> >>
> >> In general you should not really need to check this anyway, if you
> >> want to know if you are in the IO thread you should use isInIiThread()
> >> instead.
> >>
> >> Stuart
> >>
> >> On Wed, Nov 23, 2016 at 7:44 AM, Oliver Dain <oliver at analyticspot.com>
> >> wrote:
> >> > I've got some pretty simple code that looks something like:
> >> >
> >> > if (!exhange.isDispatched()) {
> >> >     exchange.dispatch(() -> {
> >> >         assert exchange.isDispatched();
> >> >          // more stuff....
> >> >     });
> >> > }
> >> >
> >> > but the assert fails. That is, when dispatch calls my runnable
> >> > isDispatched
> >> > is not true.
> >> >
> >> > I believe I have a bug somewhere with how/when dispatches are
> happening
> >> > so
> >> > I've littered my code with such asserts and they fail reliably even
> when
> >> > I'm
> >> > quite sure the exchange has been dispatched (e.g. when it is literally
> >> > the
> >> > first call in a Runnable passed to to the dispatch() method).
> >> >
> >> > What am I doing wrong?
> >> > --
> >> > CTO, Analytic Spot
> >> > 44 West Broadway #222
> >> > Eugene, OR 97401
> >> > analyticspot.com ? 425-296-6556 <(425)%20296-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 <(425)%20296-6556>
> > www.linkedin.com/in/oliverdain
>
-- 
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/20161122/e5dc44f7/attachment-0001.html 

From sdouglas at redhat.com  Tue Nov 22 17:02:52 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 23 Nov 2016 09:02:52 +1100
Subject: [undertow-dev] dispatch and isDispatched do not agree
In-Reply-To: <CACSC6EUebXFmk85GETbe3+oGirY67d5Gec6nP6E9g8Jz6BnD-g@mail.gmail.com>
References: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
	<CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>
	<CACSC6EW1NopyHxZDr9aA2jKRcEYUZC-VVY37W9mPnKXXHkC3sA@mail.gmail.com>
	<CAD+L2cyWVC3kE5ZoSjE+bPVJ0zbDv=gO6mOmekpuvnyDCJnx0w@mail.gmail.com>
	<CACSC6EUebXFmk85GETbe3+oGirY67d5Gec6nP6E9g8Jz6BnD-g@mail.gmail.com>
Message-ID: <CAD+L2cwgqnhNibrsaHuNoY39qEjPSVdT5UYjZAtyH9bOzN1FmA@mail.gmail.com>

That all sounds pretty much correct.

One thing to be aware of is that there is a difference between
dispatch(Runnable) and dispatch(HttpHandler), in that the HttpHandler
one will end the exchange when the call stack returns (unless it was
dispatched again). It sounds like the variant you want is the Runnable
one.

Stuart

On Wed, Nov 23, 2016 at 8:20 AM, Oliver Dain <oliver at analyticspot.com> wrote:
> Thanks for the clarification. I think I'm OK, but want to double check.
>
> I have some code that will pass an exchange object between thread pools not
> owned by Undertow. I can guarantee that I won't interact with the exchange
> from more than one thread at at time, but I will move it from thread pool to
> thread pool. For example, I might get a request and call dispatch. I'd then
> call a function that extracts a header from the exchange and then does an
> async lookup in a database for the info that was found in the header. When
> the DB lookup is complete I'll get a callback in a thread owned by the DB.
> In that callback I might extract another header from the exchange and then
> do another async lookup in a different database with a different thread
> pool. When that call is complete I'll get a callback in yet another thread,
> again not owned by Undertow. In that final callback I'd call
> "exchange.getResponseSender().send(...)" to send the final response.
>
> If I guarantee that I'm not operating on the exchange in more than one
> thread at a time I shouldn't have to worry about synchronization. However,
> since some async HttpServerExchange operations, like receiveFullBytes, can
> put me back on the Undertow IO pool I do need to check
> "exchange.isInIoThread()" and, if that returns true, I then need to call
> dispatch again.
>
> Does that all sound correct?
>
> On Tue, Nov 22, 2016 at 1:12 PM Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> On Wed, Nov 23, 2016 at 7:56 AM, Oliver Dain <oliver at analyticspot.com>
>> wrote:
>> > Wow! Thanks for the super-fast reply.
>> >
>> > I think I'm a little confused about the difference between being in an
>> > IO
>> > thread and being dispatched. Is it the case that if the server thinks
>> > I'm
>> > "not dispatched" (that is, if the server will send a response on my
>> > behalf
>> > when my method returns) that I'm always on an IO thread? I often do some
>> > work on my own thread pools and those threads often interact with the
>> > HttpServerExchange object. I know that some interactions with the
>> > exchange
>> > object (e.g. recieveFullBytes) will take an exchange that is in a
>> > dispatched
>> > state and put it in a non-dispatched state. So I want to just keep
>> > checking
>> > that I'm dispatched and, if I'm not, dispatch again. So my code might
>> > look
>> > something like:
>> >
>> > void handle(HttpServerExchange exchange) {
>> >     exchange.dispatch(myOwnThreadPoolExecutor, () -> {
>> >         log.info("I am not not on an IO thread and I am dispatched.");
>> >         doSomethingWithExchange(exchange);
>> >         assert exchange.isDispatched();
>> >         assert !exchange.isInIoThread();
>> >         // how do I check to see if I'm still in a dispatched state?
>> >     });
>> > }
>>
>> So the basic idea behind the 'dispatch' is that it is a way of
>> guaranteeing thread safety without needing to synchronize the exchange
>> object. Effectively it allows you to pass an exchange from one thread
>> to another in a way that guarantees that the first thread is 'done'
>> with the exchange before the second thread starts.
>>
>> >
>> > (note: the above is a bad, super-simplified example and in the actual
>> > code
>> > there's a lot of asynchronous stuff happening that bounces the execution
>> > from one thread pool to another).
>> >
>> > The reason for all of this is that I have some edge cases which appear
>> > to be
>> > race conditions in which I know for sure that I call exchange.dispatch()
>> > and
>> > then I start doing some work but the exchange gets ended before I've
>> > finished my computations and have a response to send leaving the client
>> > with
>> > an empty response. I'm not entirely sure how that could happen, but my
>> > best
>> > guess right now is that I interact with the exchange in some way that
>> > causes
>> > it to no longer be in in the dispatched state and, as a result, the
>> > HttpServerExchange is ending the exchange for me before I'm ready.
>>
>> I think I would need to look at a more specific example of what you
>> are doing, but it is possibly related to how you are handing stuff in
>> other threads? The exchange itself is not thread safe, if you start
>> doing work on the exchange in another thread without having dispatched
>> you can get a race condition.
>>
>> Stuart
>>
>> >
>> > Thanks again,
>> > Oliver
>> >
>> >
>> >
>> > On Tue, Nov 22, 2016 at 12:47 PM Stuart Douglas <sdouglas at redhat.com>
>> > wrote:
>> >>
>> >> After the call stack returns and the dispatch actually happens
>> >> isDispatched() will return false (allowing the exchange to be
>> >> dispatched again).
>> >>
>> >> In general you should not really need to check this anyway, if you
>> >> want to know if you are in the IO thread you should use isInIiThread()
>> >> instead.
>> >>
>> >> Stuart
>> >>
>> >> On Wed, Nov 23, 2016 at 7:44 AM, Oliver Dain <oliver at analyticspot.com>
>> >> wrote:
>> >> > I've got some pretty simple code that looks something like:
>> >> >
>> >> > if (!exhange.isDispatched()) {
>> >> >     exchange.dispatch(() -> {
>> >> >         assert exchange.isDispatched();
>> >> >          // more stuff....
>> >> >     });
>> >> > }
>> >> >
>> >> > but the assert fails. That is, when dispatch calls my runnable
>> >> > isDispatched
>> >> > is not true.
>> >> >
>> >> > I believe I have a bug somewhere with how/when dispatches are
>> >> > happening
>> >> > so
>> >> > I've littered my code with such asserts and they fail reliably even
>> >> > when
>> >> > I'm
>> >> > quite sure the exchange has been dispatched (e.g. when it is
>> >> > literally
>> >> > the
>> >> > first call in a Runnable passed to to the dispatch() method).
>> >> >
>> >> > What am I doing wrong?
>> >> > --
>> >> > 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
>
> --
> CTO, Analytic Spot
> 44 West Broadway #222
> Eugene, OR 97401
> analyticspot.com ? 425-296-6556
> www.linkedin.com/in/oliverdain


From oliver at analyticspot.com  Tue Nov 22 17:45:42 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Tue, 22 Nov 2016 22:45:42 +0000
Subject: [undertow-dev] dispatch and isDispatched do not agree
In-Reply-To: <CAD+L2cwgqnhNibrsaHuNoY39qEjPSVdT5UYjZAtyH9bOzN1FmA@mail.gmail.com>
References: <CACSC6EXPViRBYBdeEvZHtUPfBerUaNb5gGidL7myfAARVB2S9A@mail.gmail.com>
	<CAD+L2cyy4YOKmR6ygP9hGF7xTwXbx6Zjm6QT7tAEbxWzrYZXqQ@mail.gmail.com>
	<CACSC6EW1NopyHxZDr9aA2jKRcEYUZC-VVY37W9mPnKXXHkC3sA@mail.gmail.com>
	<CAD+L2cyWVC3kE5ZoSjE+bPVJ0zbDv=gO6mOmekpuvnyDCJnx0w@mail.gmail.com>
	<CACSC6EUebXFmk85GETbe3+oGirY67d5Gec6nP6E9g8Jz6BnD-g@mail.gmail.com>
	<CAD+L2cwgqnhNibrsaHuNoY39qEjPSVdT5UYjZAtyH9bOzN1FmA@mail.gmail.com>
Message-ID: <CACSC6EVVMVWKJ7U8onJnSqTAVPrBB3DgY=guO2i_s05dsR7LuQ@mail.gmail.com>

Got it. Thanks!!

On Tue, Nov 22, 2016, 2:02 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> That all sounds pretty much correct.
>
> One thing to be aware of is that there is a difference between
> dispatch(Runnable) and dispatch(HttpHandler), in that the HttpHandler
> one will end the exchange when the call stack returns (unless it was
> dispatched again). It sounds like the variant you want is the Runnable
> one.
>
> Stuart
>
> On Wed, Nov 23, 2016 at 8:20 AM, Oliver Dain <oliver at analyticspot.com>
> wrote:
> > Thanks for the clarification. I think I'm OK, but want to double check.
> >
> > I have some code that will pass an exchange object between thread pools
> not
> > owned by Undertow. I can guarantee that I won't interact with the
> exchange
> > from more than one thread at at time, but I will move it from thread
> pool to
> > thread pool. For example, I might get a request and call dispatch. I'd
> then
> > call a function that extracts a header from the exchange and then does an
> > async lookup in a database for the info that was found in the header.
> When
> > the DB lookup is complete I'll get a callback in a thread owned by the
> DB.
> > In that callback I might extract another header from the exchange and
> then
> > do another async lookup in a different database with a different thread
> > pool. When that call is complete I'll get a callback in yet another
> thread,
> > again not owned by Undertow. In that final callback I'd call
> > "exchange.getResponseSender().send(...)" to send the final response.
> >
> > If I guarantee that I'm not operating on the exchange in more than one
> > thread at a time I shouldn't have to worry about synchronization.
> However,
> > since some async HttpServerExchange operations, like receiveFullBytes,
> can
> > put me back on the Undertow IO pool I do need to check
> > "exchange.isInIoThread()" and, if that returns true, I then need to call
> > dispatch again.
> >
> > Does that all sound correct?
> >
> > On Tue, Nov 22, 2016 at 1:12 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> On Wed, Nov 23, 2016 at 7:56 AM, Oliver Dain <oliver at analyticspot.com>
> >> wrote:
> >> > Wow! Thanks for the super-fast reply.
> >> >
> >> > I think I'm a little confused about the difference between being in an
> >> > IO
> >> > thread and being dispatched. Is it the case that if the server thinks
> >> > I'm
> >> > "not dispatched" (that is, if the server will send a response on my
> >> > behalf
> >> > when my method returns) that I'm always on an IO thread? I often do
> some
> >> > work on my own thread pools and those threads often interact with the
> >> > HttpServerExchange object. I know that some interactions with the
> >> > exchange
> >> > object (e.g. recieveFullBytes) will take an exchange that is in a
> >> > dispatched
> >> > state and put it in a non-dispatched state. So I want to just keep
> >> > checking
> >> > that I'm dispatched and, if I'm not, dispatch again. So my code might
> >> > look
> >> > something like:
> >> >
> >> > void handle(HttpServerExchange exchange) {
> >> >     exchange.dispatch(myOwnThreadPoolExecutor, () -> {
> >> >         log.info("I am not not on an IO thread and I am
> dispatched.");
> >> >         doSomethingWithExchange(exchange);
> >> >         assert exchange.isDispatched();
> >> >         assert !exchange.isInIoThread();
> >> >         // how do I check to see if I'm still in a dispatched state?
> >> >     });
> >> > }
> >>
> >> So the basic idea behind the 'dispatch' is that it is a way of
> >> guaranteeing thread safety without needing to synchronize the exchange
> >> object. Effectively it allows you to pass an exchange from one thread
> >> to another in a way that guarantees that the first thread is 'done'
> >> with the exchange before the second thread starts.
> >>
> >> >
> >> > (note: the above is a bad, super-simplified example and in the actual
> >> > code
> >> > there's a lot of asynchronous stuff happening that bounces the
> execution
> >> > from one thread pool to another).
> >> >
> >> > The reason for all of this is that I have some edge cases which appear
> >> > to be
> >> > race conditions in which I know for sure that I call
> exchange.dispatch()
> >> > and
> >> > then I start doing some work but the exchange gets ended before I've
> >> > finished my computations and have a response to send leaving the
> client
> >> > with
> >> > an empty response. I'm not entirely sure how that could happen, but my
> >> > best
> >> > guess right now is that I interact with the exchange in some way that
> >> > causes
> >> > it to no longer be in in the dispatched state and, as a result, the
> >> > HttpServerExchange is ending the exchange for me before I'm ready.
> >>
> >> I think I would need to look at a more specific example of what you
> >> are doing, but it is possibly related to how you are handing stuff in
> >> other threads? The exchange itself is not thread safe, if you start
> >> doing work on the exchange in another thread without having dispatched
> >> you can get a race condition.
> >>
> >> Stuart
> >>
> >> >
> >> > Thanks again,
> >> > Oliver
> >> >
> >> >
> >> >
> >> > On Tue, Nov 22, 2016 at 12:47 PM Stuart Douglas <sdouglas at redhat.com>
> >> > wrote:
> >> >>
> >> >> After the call stack returns and the dispatch actually happens
> >> >> isDispatched() will return false (allowing the exchange to be
> >> >> dispatched again).
> >> >>
> >> >> In general you should not really need to check this anyway, if you
> >> >> want to know if you are in the IO thread you should use
> isInIiThread()
> >> >> instead.
> >> >>
> >> >> Stuart
> >> >>
> >> >> On Wed, Nov 23, 2016 at 7:44 AM, Oliver Dain <
> oliver at analyticspot.com>
> >> >> wrote:
> >> >> > I've got some pretty simple code that looks something like:
> >> >> >
> >> >> > if (!exhange.isDispatched()) {
> >> >> >     exchange.dispatch(() -> {
> >> >> >         assert exchange.isDispatched();
> >> >> >          // more stuff....
> >> >> >     });
> >> >> > }
> >> >> >
> >> >> > but the assert fails. That is, when dispatch calls my runnable
> >> >> > isDispatched
> >> >> > is not true.
> >> >> >
> >> >> > I believe I have a bug somewhere with how/when dispatches are
> >> >> > happening
> >> >> > so
> >> >> > I've littered my code with such asserts and they fail reliably even
> >> >> > when
> >> >> > I'm
> >> >> > quite sure the exchange has been dispatched (e.g. when it is
> >> >> > literally
> >> >> > the
> >> >> > first call in a Runnable passed to to the dispatch() method).
> >> >> >
> >> >> > What am I doing wrong?
> >> >> > --
> >> >> > 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
> >
> > --
> > CTO, Analytic Spot
> > 44 West Broadway #222
> > Eugene, OR 97401
> > analyticspot.com ? 425-296-6556
> > www.linkedin.com/in/oliverdain
>
-- 
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/20161122/9d577251/attachment-0001.html 

From kid at bitkid.com  Tue Nov 29 08:03:51 2016
From: kid at bitkid.com (Sascha Sadat-Guscheh)
Date: Tue, 29 Nov 2016 14:03:51 +0100
Subject: [undertow-dev] start listener on random port
Message-ID: <647E77CD-9236-481A-92CE-AB52EBCB5F58@bitkid.com>

hello undertow developers!

is there a way to start a http listener on a random free port? i have a test suite that runs multithreaded so each untertow server uses a random port, that i get like this:

new ServerSocket(0).getLocalPort()

sometimes i run into a race condition when a different process grabs the port before undertow listens on it.  so a possible solution would be to just let undertow assign the port, and then ask it what port its listening on. (or pass the socket instead of the port number to undertow)

is that a worthwile feature? should i try to submit a pr that does that? or is it already possible?

thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20161129/5ae04e8c/attachment.bin 

From devl.development at gmail.com  Tue Nov 29 10:33:07 2016
From: devl.development at gmail.com (Devl Devel)
Date: Tue, 29 Nov 2016 15:33:07 +0000
Subject: [undertow-dev] Websocket Data
Message-ID: <CAMQ+LQNc6CbuiheEOKOrpdco6FHTn-j0OebW2RObTJd69oP0Hw@mail.gmail.com>

Hi Guys

I managed to implement a websocket server as per
https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/chat/ChatServer.java

Question is whats the best way to get the websocket to send data every 1 or
x second(x) irrespective of whether it got a message via onFullTextMessage?

Any pointers would be appreciated.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20161129/99d221a8/attachment.html 

From sdouglas at redhat.com  Tue Nov 29 15:25:20 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 30 Nov 2016 07:25:20 +1100
Subject: [undertow-dev] Websocket Data
In-Reply-To: <CAMQ+LQNc6CbuiheEOKOrpdco6FHTn-j0OebW2RObTJd69oP0Hw@mail.gmail.com>
References: <CAMQ+LQNc6CbuiheEOKOrpdco6FHTn-j0OebW2RObTJd69oP0Hw@mail.gmail.com>
Message-ID: <CAD+L2cxzugRXOooqR2JHW-QEM5cnvPofK0uYr+V0RWhx8y+ttg@mail.gmail.com>

You can use

XnioIoThread.executeAtInterval

One thing to be careful of though is that you need to make sure the
messages are actually being sent. If the messages are very large and
the client is very slow you can eventually run out of memory due to
messages being buffered.

Stuart

On Wed, Nov 30, 2016 at 2:33 AM, Devl Devel <devl.development at gmail.com> wrote:
> Hi Guys
>
> I managed to implement a websocket server as per
> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/chat/ChatServer.java
>
> Question is whats the best way to get the websocket to send data every 1 or
> x second(x) irrespective of whether it got a message via onFullTextMessage?
>
> Any pointers would be appreciated.
> Thanks
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From ferrerabertran at gmail.com  Wed Nov 30 05:53:03 2016
From: ferrerabertran at gmail.com (Pere Ferrera)
Date: Wed, 30 Nov 2016 11:53:03 +0100
Subject: [undertow-dev] two questions
Message-ID: <CAKKbXwiKudHYze5DS103=-7ochhjASODPYar_31cwQFVvNbX2Q@mail.gmail.com>

Hi there,
I have two questions: 1) How can I configure the underlying socket
parameter SO_LINGER using the Undertow API ? and 2) Is there something that
I can use to rate-limit requests issued to an Undertow server ? (something
similar to the DoS Filter in Jetty)

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20161130/3fd9d55a/attachment.html 

From sdouglas at redhat.com  Wed Nov 30 16:23:39 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 1 Dec 2016 08:23:39 +1100
Subject: [undertow-dev] two questions
In-Reply-To: <CAKKbXwiKudHYze5DS103=-7ochhjASODPYar_31cwQFVvNbX2Q@mail.gmail.com>
References: <CAKKbXwiKudHYze5DS103=-7ochhjASODPYar_31cwQFVvNbX2Q@mail.gmail.com>
Message-ID: <CAD+L2cxJ6cQS8oNDbR7epC6FFn2ZD_LT5YX0yf-HaidGsPN=Pw@mail.gmail.com>

1) Why do you need to set this? In general Undertow won't close the
socket until all messages have been sent anyway.

2) Do you mean limit the number of active requests, or limit the
number of bytes per second that can be sent?

io.undertow.server.handlers.RequestLimitingHandler can limit the
number of active requests, while
io.undertow.server.handlers.ResponseRateLimitingHandler can be used to
limit the rate data is sent on a connection.

Stuart

On Wed, Nov 30, 2016 at 9:53 PM, Pere Ferrera <ferrerabertran at gmail.com> wrote:
> Hi there,
> I have two questions: 1) How can I configure the underlying socket parameter
> SO_LINGER using the Undertow API ? and 2) Is there something that I can use
> to rate-limit requests issued to an Undertow server ? (something similar to
> the DoS Filter in Jetty)
>
> Thanks,
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Wed Nov 30 16:24:21 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 1 Dec 2016 08:24:21 +1100
Subject: [undertow-dev] start listener on random port
In-Reply-To: <647E77CD-9236-481A-92CE-AB52EBCB5F58@bitkid.com>
References: <647E77CD-9236-481A-92CE-AB52EBCB5F58@bitkid.com>
Message-ID: <CAD+L2czvJ15PccdgNxRqkRp96aC-=q0cy1wbQJw26cFQWUkLPw@mail.gmail.com>

We don't support this at the moment, but it would be something that is
nice to have.

Stuart

On Wed, Nov 30, 2016 at 12:03 AM, Sascha Sadat-Guscheh <kid at bitkid.com> wrote:
> hello undertow developers!
>
> is there a way to start a http listener on a random free port? i have a test suite that runs multithreaded so each untertow server uses a random port, that i get like this:
>
> new ServerSocket(0).getLocalPort()
>
> sometimes i run into a race condition when a different process grabs the port before undertow listens on it.  so a possible solution would be to just let undertow assign the port, and then ask it what port its listening on. (or pass the socket instead of the port number to undertow)
>
> is that a worthwile feature? should i try to submit a pr that does that? or is it already possible?
>
> thanks!
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev