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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev