[wildfly-dev] WF 8.0 HTTP Upgrade help needed

Przemyslaw Bielicki pbielicki at gmail.com
Thu Apr 3 14:42:38 EDT 2014


Hi Jason,

that would be great. I appreciate.

Take your time, it'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 :)

Cheers,
Przemyslaw
3 kwi 2014 20:31 "Jason T. Greene" <jgreene at redhat.com> napisał(a):

> 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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/6cbcfaa4/attachment-0001.html 


More information about the wildfly-dev mailing list