Let me play with your use case, although it will be a few hours before I can get to it.

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's basically an async deferred write. 

The undertow http handler API is, in my opinion a much better fit for pure non-blocking / reactive applications. 

On Apr 3, 2014, at 9:52 AM, Przemyslaw Bielicki <pbielicki@gmail.com> wrote:

As I showed  I'm not able to read and write at the same time using non-blocking IO, as promised by Servlet 3.1. I'm able to read using non-blocking IO but my writes are blocking and I'm looking for the solution.

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'm not.

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'm the master of my protocol and I'm no longer bound to HTTP - I can be as asynchronous as I want. Unfortunately Servlet 3.1 API does not respect this.

It looks like the specification is not meeting the promises given....

On Thu, Apr 3, 2014 at 4:41 PM, Rémy Maucherat <rmaucher@redhat.com> wrote:

On 03/04/2014 15:21, Przemyslaw Bielicki wrote:
> I tried - exactly the same results.
>
> Another weird observation is that ServletOutputStream.isReady() is
> returning true even after the connection is closed
> (ServletInputStream.isFinished() is correctly returning true).
>
> Here's the scenario that works but I can write back the data only once:
> 1. In HttpUpgradeHandler I set only  the ReadListener
> 2. I switch the protocol and send some data
> 3. ReadListener gets activated i.e. onDataAvailable() is called.
> 4. I process the input data, read as much as possible and put the
> input into the queue
> 5. From within ReadListener I set the WriteListener
> 6. WriteListener.onWritePossible() gets called and I process the data
> - I clean the queue
> 7. As long as I'm in WriteListener.onWritePossible()
> (while.out.isReady() is constantly returning true, which is a correct
> bahavior) the ReadListener is on-hold. I can send as much data as I
> like but onDataAvailable() is not called
> 8. Only when I leave WriteListener.onWritePossible() method the
> ReadListener.onDataAvailable() is called again and I can consume the
> input data again.
> 9. I can process the input data again i.e. put it into the queue but
> WriteListener.onWritePossible() is never called again. When I try to
> reset it I get IllegalStateException
>
> Either the specification or implementation seem not very mature....
> Wildfly behavior is consistent with the one of Tomcat.
>
> At the moment I conclude that the non-blocking write is not possible
> in Servlet 3.1.
>
> I would appreciate if someone can provide an example that actually
> works or explain why the weird behavior I observe is correct (is it?)

This looks as expected (although Tomcat 8 should concurrently call
read/write in upgraded mode, as a proprietary extension to be able to
implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is
still not concurrent, so at most one thread processing a request a given
time).

Non blocking IO means it allows avoiding to block on IO, it doesn't
imply anything else. Servlets 3.1 is actually async IO (similar to NIO2,
rather than NIO1), since non blocking IO is unusable as is.

Rémy

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev