<p dir="ltr">Hi Jason, </p>
<p dir="ltr">that would be great. I appreciate.</p>
<p dir="ltr">Take your time, it&#39;s not super urgent but I would like to have a complete example of the full-duplex upgrade mechanism using standard API. Then I would be more than interested in seeing how I can employ undertow to do the job :)</p>

<p dir="ltr">Cheers,<br>
Przemyslaw</p>
<div class="gmail_quote">3 kwi 2014 20:31 &quot;Jason T. Greene&quot; &lt;<a href="mailto:jgreene@redhat.com">jgreene@redhat.com</a>&gt; napisał(a):<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>Let me play with your use case, although it will be a few hours before I can get to it.</div><div><br></div><div>There are some limitations to the spec, but they are manageable. As an example the write is actually written for you in a non blocking fashion. It&#39;s basically an async deferred write. </div>
<div><br></div><div>The undertow http handler API is, in my opinion a much better fit for pure non-blocking / reactive applications. </div><div><br>On Apr 3, 2014, at 9:52 AM, Przemyslaw Bielicki &lt;<a href="mailto:pbielicki@gmail.com" target="_blank">pbielicki@gmail.com</a>&gt; wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr"><div><div>As I showed  I&#39;m not able to read and write at the same time using non-blocking IO, as promised by Servlet 3.1. I&#39;m able to read using non-blocking IO but my writes are blocking and I&#39;m looking for the solution.<br>

<br>Regarding concurrent access, HTTP Upgrade promises that the upgraded protocol will be full-duplex, so I should be able to read and write concurrently but I&#39;m not.<br></div><br>Another comment is that Servlets 3.1 is actually async ONLY from the server point of view - the client is still blocked because HTTP 1.1 is synchronous (we have to wait for HTTP 2.0 to solve this). Here Upgrade should help as it is a pure TCP, so I&#39;m the master of my protocol and I&#39;m no longer bound to HTTP - I can be as asynchronous as I want. Unfortunately Servlet 3.1 API does not respect this.<br>

<br></div>It looks like the specification is not meeting the promises given....<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 4:41 PM, Rémy Maucherat <span dir="ltr">&lt;<a href="mailto:rmaucher@redhat.com" target="_blank">rmaucher@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 03/04/2014 15:21, Przemyslaw Bielicki wrote:<br>
&gt; I tried - exactly the same results.<br>
&gt;<br>
&gt; Another weird observation is that ServletOutputStream.isReady() is<br>
&gt; returning true even after the connection is closed<br>
&gt; (ServletInputStream.isFinished() is correctly returning true).<br>
&gt;<br>
&gt; Here&#39;s the scenario that works but I can write back the data only once:<br>
&gt; 1. In HttpUpgradeHandler I set only  the ReadListener<br>
&gt; 2. I switch the protocol and send some data<br>
&gt; 3. ReadListener gets activated i.e. onDataAvailable() is called.<br>
&gt; 4. I process the input data, read as much as possible and put the<br>
&gt; input into the queue<br>
&gt; 5. From within ReadListener I set the WriteListener<br>
&gt; 6. WriteListener.onWritePossible() gets called and I process the data<br>
&gt; - I clean the queue<br>
&gt; 7. As long as I&#39;m in WriteListener.onWritePossible()<br>
&gt; (while.out.isReady() is constantly returning true, which is a correct<br>
&gt; bahavior) the ReadListener is on-hold. I can send as much data as I<br>
&gt; like but onDataAvailable() is not called<br>
&gt; 8. Only when I leave WriteListener.onWritePossible() method the<br>
&gt; ReadListener.onDataAvailable() is called again and I can consume the<br>
&gt; input data again.<br>
&gt; 9. I can process the input data again i.e. put it into the queue but<br>
&gt; WriteListener.onWritePossible() is never called again. When I try to<br>
&gt; reset it I get IllegalStateException<br>
&gt;<br>
&gt; Either the specification or implementation seem not very mature....<br>
&gt; Wildfly behavior is consistent with the one of Tomcat.<br>
&gt;<br>
&gt; At the moment I conclude that the non-blocking write is not possible<br>
&gt; in Servlet 3.1.<br>
&gt;<br>
&gt; I would appreciate if someone can provide an example that actually<br>
&gt; works or explain why the weird behavior I observe is correct (is it?)<br>
</div></div>This looks as expected (although Tomcat 8 should concurrently call<br>
read/write in upgraded mode, as a proprietary extension to be able to<br>
implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is<br>
still not concurrent, so at most one thread processing a request a given<br>
time).<br>
<br>
Non blocking IO means it allows avoiding to block on IO, it doesn&#39;t<br>
imply anything else. Servlets 3.1 is actually async IO (similar to NIO2,<br>
rather than NIO1), since non blocking IO is unusable as is.<br>
<span><font color="#888888"><br>
Rémy<br>
</font></span><div><div><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>wildfly-dev mailing list</span><br><span><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span></div></blockquote></div></blockquote></div>