<div dir="ltr">Yes. The worker thread will not start executing the handler until the current stack has returned, at which point the IO thread will no longer have anything to do with the exchange (it has handed it off to the worker thread). <div><br></div><div>You can then invoke any method, as anything that will involve the IO thread is deferred until after the worker thread has returned. </div><div><br></div><div>Stuart</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 26, 2018 at 9:54 AM R. Matt Barnett <<a href="mailto:barnett@rice.edu">barnett@rice.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>So just to be clear, am I correct in my understanding that is it
safe to invoke any method on the Sender instance returned by
getResponseSender() from a Worker Thread without any extra
threading considerations? Can you confirm this is true as well
for the HeaderMap instance returned by getResponseHeaders() and
also for invocations of setStatusCode(...) ?</p>
<p>Thanks.<br>
</p>
<br>
<div class="m_-1794236830175320787moz-cite-prefix">On 7/25/2018 6:31 PM, Stuart Douglas
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Jul 26, 2018 at 5:27 AM R. Matt Barnett
<<a href="mailto:barnett@rice.edu" target="_blank">barnett@rice.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>I've been able to observe 1...8 on Red Hat by adding
the following statements to my handler (and setting the
worker thread pool size to 8):</p>
<p><br>
</p>
<blockquote>
<pre class="m_-1794236830175320787m_-6063288014349793603CodeRay m_-1794236830175320787m_-6063288014349793603highlight m_-1794236830175320787m_-6063288014349793603nowrap"><span style="color:#808000">@Override
</span><span style="color:#000080;font-weight:bold">public void </span>handleRequest(HttpServerExchange httpServerExchange) <span style="color:#000080;font-weight:bold">throws </span>Exception
{
<span style="color:#000080;font-weight:bold">if </span>(httpServerExchange.isInIoThread()) {
httpServerExchange.dispatch(<span style="color:#000080;font-weight:bold">this</span>);
<span style="color:#000080;font-weight:bold">return</span>;
}
...
}
</pre>
</blockquote>
<pre class="m_-1794236830175320787m_-6063288014349793603CodeRay m_-1794236830175320787m_-6063288014349793603highlight m_-1794236830175320787m_-6063288014349793603nowrap">I have a few questions about this technique though:
1.) How are dispatch actions mapped onto worker threads? New connections were not mapped to available idle IO threads, so is it possible dispatches also won't be mapped to available idle worker threads but instead queued for currently
busy threads?</pre>
</div>
</blockquote>
<div><br>
</div>
<div>IO threads are tied to the connection. Once a connection
has been accepted only that IO thread will be used to
service it. This avoids contention from having a larger
number of IO threads waiting on a single selector. The
worker thread pool is basically just a normal executor, that
will run tasks in a FIFO manner.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<pre class="m_-1794236830175320787m_-6063288014349793603CodeRay m_-1794236830175320787m_-6063288014349793603highlight m_-1794236830175320787m_-6063288014349793603nowrap">2.) The Undertow documentation states that HttpServerExchange is not thread-safe. However the documentation states that dispatch(...) has happens-before semantics with respect to the worker thread accessing httpServerExchange.
That would seem to make it ok to read from httpServerExchange in the worker thread. Assuming that an IO thread will be responsible for writing the http response back to the client, what steps do I need to take in the body
of <span style="color:#000080;font-weight:bold"></span>handleRequest to ensure that my writes to httpServerExchange in the worker thread are observed by the IO thread responsible for transmitting the response to the client? Is invoking httpServerExchange.endExchange(); in the
worker thread as the final statement sufficient? </pre>
</div>
</blockquote>
<div><br>
</div>
<div>Not all writes are done from the IO thread. For instance
if you use blocking IO and are using a Stream then the
writes are done from the worker.</div>
<div><br>
</div>
<div>If you use the Sender to perform async IO then the
initial write is done from the original thread, and the IO
thread is only involved if the response is too larger to
just write out immediately. In this case though the Sender
will take care of the thread safety aspects, as the
underlying SelectionKey will not have its interest ops set
until after the current stack has returned. </div>
<div><br>
</div>
<div>Basically if you call dispatch(), or perform an action
that requires async IO nothing happens immediately, it just
sets a flag in the HttpServerExchange. Once the call stack
returns (i.e. the current thread is done) one of three
things will happen:</div>
<div>- If dispatch was called the dispatch task will be run in
an executor</div>
<div>- If async IO was required the underlying SelectionKey
will have its interest ops modified, so the IO thread can
perform the IO</div>
<div>- If neither of the above happened then the exchange is
ended.</div>
<div><br>
</div>
<div>Stuart</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <br>
-- Matt<br>
<br>
<div class="m_-1794236830175320787m_-6063288014349793603moz-cite-prefix">On
7/25/2018 11:26 AM, R. Matt Barnett wrote:<br>
</div>
<blockquote type="cite">
<pre>Corrected test to resolve test/set race.
<a class="m_-1794236830175320787m_-6063288014349793603moz-txt-link-freetext" href="https://gist.github.com/rmbarnett-rice/1179c4ad1d3344bb247c8b8daed3e4fa" target="_blank">https://gist.github.com/rmbarnett-rice/1179c4ad1d3344bb247c8b8daed3e4fa</a>
I've also discovered this morning that I *can* see 1-8 printed on Red
Hat when I generate load using ab from Windows, but only 1-4 when
running ab on Red Hat (both locally and from a remote server). I'm
wondering if perhaps there is some sort of connection reuse shenanigans
going on. My assumption of the use of the -c 8 parameter was "make 8
sockets" but maybe not. I'll dig in and report back.
-- Matt
On 7/24/2018 6:56 PM, R. Matt Barnett wrote:
</pre>
<blockquote type="cite">
<pre>Hello,
I'm experiencing an Undertow performance issue I fail to understand. I
am able to reproduce the issue with the code linked bellow. The problem
is that on Red Hat (and not Windows) I'm unable to concurrently process
more than 4 overlapping requests even with 8 configured IO Threads.
For example, if I run the following program (1 file, 55 lines):
<a class="m_-1794236830175320787m_-6063288014349793603moz-txt-link-freetext" href="https://gist.github.com/rmbarnett-rice/668db6b4e9f8f8da7093a3659b6ae2b5" target="_blank">https://gist.github.com/rmbarnett-rice/668db6b4e9f8f8da7093a3659b6ae2b5</a>
... on Red Hat and then send requests to the server using Apache
Benchmark...
> ab -n 1000 -c 8 localhost:8080/
I see the following output from the Undertow process:
Server started on port 8080
1
2
3
4
I believe this demonstrates that only 4 requests are ever processed in
parallel. I would expect 8. In fact, when I run the same experiment on
Windows I see the expected output of
Server started on port 8080
1
2
3
4
5
6
7
8
Any thoughts as to what might explain this behavior?
Best,
Matt
_______________________________________________
undertow-dev mailing list
<a class="m_-1794236830175320787m_-6063288014349793603moz-txt-link-abbreviated" href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a>
<a class="m_-1794236830175320787m_-6063288014349793603moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a>
</pre>
</blockquote>
<pre>_______________________________________________
undertow-dev mailing list
<a class="m_-1794236830175320787m_-6063288014349793603moz-txt-link-abbreviated" href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a>
<a class="m_-1794236830175320787m_-6063288014349793603moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
undertow-dev mailing list<br>
<a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a></blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div>