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?)
Cheers,
Przemyslaw
On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
<stuart.w.douglas(a)gmail.com>wrote:
Can you try with the latest development build of Wildfly (from
https://ci.jboss.org/hudson/job/WildFly-latest-master/).
There have been some fixes in this area, so your problem may have already
been fixed.
Stuart
PB wrote:
> Hi,
>
> I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing some banal
> problem. Basically my ReadListener is NEVER called.
> Here's the code:
>
> @WebServlet(urlPatterns = "/upgrade")
> public class UpgradeServlet extends HttpServlet {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse
> resp) throws ServletException, IOException {
> if ("upgrade".equalsIgnoreCase(req.getHeader("Connection")))
{
> req.upgrade(EchoHandler.class);
> }
> }
> }
>
> public class EchoHandler implements HttpUpgradeHandler {
> @Override
> public void init(WebConnection wc) {
> try {
> ServletInputStream in = wc.getInputStream();
> ServletOutputStream out = wc.getOutputStream();
>
> BlockingQueue<String> queue = new LinkedBlockingQueue<String>();
> in.setReadListener(new EchoReadListener(queue, in));
> out.setWriteListener(new EchoWriteListener(queue, out));
> } catch (IOException e) {
> throw new IllegalStateException(e);
> }
> }
>
> public class EchoReadListener implements ReadListener {
> @Override
> public void onDataAvailable() throws IOException {
> while (in.isReady()) {
> int length = in.read(buffer);
> String input = new String(buffer, 0, length);
> if (false == queue.offer(input)) {
> System.err.println("'" + input + "' input was
ignored");
> }
> }
> }
>
> I'm connecting to WF using telnet and sending the upgrade request:
> GET /example-webapp/upgrade HTTP/1.1
> Host: localhost
> Connection: upgrade
> Upgrade: echo
>
> and I'm getting correct response:
>
> HTTP/1.1 101 Switching Protocols
> Connection: Upgrade
> X-Powered-By: Undertow 1
> Server: Wildfly 8
> Content-Length: 0
>
> which means that from now on the protocol between my telnet client and
> WF is pure TCP.
> So, I start typing some text, hit Enter and.... nothing happens.
> onDataAvailable() is NEVER called. More so, this makes WF totally
> irresponsive - my whole webapp is dead.
>
> I believe, I'm doing something wrong - any ideas what exactly? There is
> also a slight chance that Upgrade feature in WF is f****d :)
> Anyway, WF should not block even in case my upgraded protocol is not
> working correctly?
>
> Many thanks,
> Przemyslaw
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>