I have a dream about continuations...

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

I have a dream about continuations...

Daniel Burkes-2
Hello all-

I saw some old messages around this topic, but none in a while, so I  
thought I'd re-ask.

What I would like to do is take an incoming request, suspend it,  
resume, write some partial response, suspend again, resume, write  
more partial response, etc.  So the pattern looks like:

1. receive request
2. suspend
3. resume
4. write partial response
5. Repeat steps 2-4 indefinitely
6. Eventually close request

This would be useful for comet applications that want to use the  
multipart/x-mixed-replace hack, or partial evaluations in browsers.

I have written a small servlet to test this, but, whenever I write  
data to the response object (step 4, above), Jetty insists on closing  
the connection, even if I call continuation.suspend() before  
returning from HttpServlet#doGet.

Am I crazy or should this be possible?

Best Regards,

Danny Burkes
http://www.lingr.com

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

mqperson
It worked perfectly fine for me.  Please post your code and I'll see
what's wrong with it.

Best,
Anjul.

<quote who="Daniel Burkes">

> Hello all-
>
> I saw some old messages around this topic, but none in a while, so I
> thought I'd re-ask.
>
> What I would like to do is take an incoming request, suspend it,
> resume, write some partial response, suspend again, resume, write
> more partial response, etc.  So the pattern looks like:
>
> 1. receive request
> 2. suspend
> 3. resume
> 4. write partial response
> 5. Repeat steps 2-4 indefinitely
> 6. Eventually close request
>
> This would be useful for comet applications that want to use the
> multipart/x-mixed-replace hack, or partial evaluations in browsers.
>
> I have written a small servlet to test this, but, whenever I write
> data to the response object (step 4, above), Jetty insists on closing
> the connection, even if I call continuation.suspend() before
> returning from HttpServlet#doGet.
>
> Am I crazy or should this be possible?
>
> Best Regards,
>
> Danny Burkes
> http://www.lingr.com
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

Daniel Burkes-2
> It worked perfectly fine for me.  Please post your code and I'll see
> what's wrong with it.
>

Below is my dead-simple test servlet.  If I do "curl -v -v -v http://
localhost:8080/foo.html", I see that Jetty closes the connection  
after the first mime part is written, even though I call  
continuation.suspend() subsequent to writing it.

Best Regards,

Danny

=== cut here ===

public class MyServlet extends HttpServlet
{
        protected void doGet(HttpServletRequest request,
                HttpServletResponse response)
                throws ServletException, IOException
        {
                if (continuation != null && continuation.isResumed())
                {
                        if (continuation.getObject() == null)
                        {
                                response.setHeader("Content-Type", "multipart/x-mixed-replace;  
boundary=\"foo\"");
                                response.setHeader("MIME-version", "1.0");
                                response.getOutputStream().write("This is a multipart comet  
response\r\n".getBytes());
                               
                                continuation.setObject(new Boolean(true));
                        }

                        response.getOutputStream().write("--foo\r\n".getBytes());
                        response.getOutputStream().write("Content-Type: text/plain\r\n\r
\n".getBytes());
                        response.getOutputStream().write("Hello!\r\n".getBytes());
                        response.flushBuffer();
                       
                        continuation.suspend(5000);
                }
                else
                {
                        continuation = ContinuationSupport.getContinuation(request, null);
                        continuation.suspend(5000);
                }
        }

        private static Continuation continuation;
}


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

mqperson
It did not seem dead-simple because it was mixed with the multi-part stuff
(which adds more moving parts and adds uncertainty whether if the problem
is with continuations or something else)

Here's what I simplified it to, and this works with my installation of
jetty 6.1.1.  I added the call to continuation.reset() which is probably
the only thing I can flag as what made it work.

What I would recommend is starting out from this working case and add more
complexity without breaking anything.  If something breaks, I would first
test the multi-part response WITHOUT continuation and then try to
demonstrate that it breaks simply by adding continuations.

Code:
===============
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.mortbay.util.ajax.*;

public class MyServlet extends HttpServlet
{
  protected void doGet(HttpServletRequest request,
  HttpServletResponse response)
  throws ServletException, IOException
  {
    Continuation continuation =
ContinuationSupport.getContinuation(request, null);

    if (continuation.getObject() == null)
    {
      System.out.println("debug: first");
      response.setContentType("text/html");
      response.getWriter().println("<html><body><h1>Hello</h1>");
      response.getWriter().flush();
      continuation.setObject(new Boolean(true));
    } else {
      System.out.println("debug: subsequent");
      response.getWriter().println("<h1>Hello again</h1>");
      response.getWriter().flush();
    }

    continuation.reset();
    continuation.suspend(5000);
  }
}

===============

Best,
Anjul.

<quote who="Daniel Burkes">

>> It worked perfectly fine for me.  Please post your code and I'll see
>> what's wrong with it.
>>
>
> Below is my dead-simple test servlet.  If I do "curl -v -v -v http://
> localhost:8080/foo.html", I see that Jetty closes the connection
> after the first mime part is written, even though I call
> continuation.suspend() subsequent to writing it.
>
> Best Regards,
>
> Danny
>
> === cut here ===
>
> public class MyServlet extends HttpServlet
> {
> protected void doGet(HttpServletRequest request,
> HttpServletResponse response)
> throws ServletException, IOException
> {
> if (continuation != null && continuation.isResumed())
> {
> if (continuation.getObject() == null)
> {
> response.setHeader("Content-Type", "multipart/x-mixed-replace;
> boundary=\"foo\"");
> response.setHeader("MIME-version", "1.0");
> response.getOutputStream().write("This is a multipart comet
> response\r\n".getBytes());
>
> continuation.setObject(new Boolean(true));
> }
>
> response.getOutputStream().write("--foo\r\n".getBytes());
> response.getOutputStream().write("Content-Type: text/plain\r\n\r
> \n".getBytes());
> response.getOutputStream().write("Hello!\r\n".getBytes());
> response.flushBuffer();
>
> continuation.suspend(5000);
> }
> else
> {
> continuation = ContinuationSupport.getContinuation(request, null);
> continuation.suspend(5000);
> }
> }
>
> private static Continuation continuation;
> }
>
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

Daniel Burkes-2
> Here's what I simplified it to, and this works with my installation of
> jetty 6.1.1.  I added the call to continuation.reset() which is  
> probably
> the only thing I can flag as what made it work.
>

That was the ticket- adding continuation.reset() to my original code  
made Jetty happy.  Now, on to figuring out how to make the client  
side evaluate each mime part separately.

Thanks!

Danny

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

Greg Wilkins
Danny Burkes wrote:
>> Here's what I simplified it to, and this works with my installation of
>> jetty 6.1.1.  I added the call to continuation.reset() which is  
>> probably
>> the only thing I can flag as what made it work.
>>
>
> That was the ticket- adding continuation.reset() to my original code  
> made Jetty happy.  Now, on to figuring out how to make the client  
> side evaluate each mime part separately.

and there in lies the problems of forever responses!

I really think that long polling is better, ie where a complete
response is always sent and a new request is issues immediately
afterwards.

Even with the multipart response, a packet needs to be sent from the
client to the server to ack the flushed data.  It might as well have
the extra 10s of bytes needed to make the next request.

Specially seeing that most forever responses systems end up
sending 4k of spaces to make IE buffers overflow and react
to the flushed data.

cheers


--
Greg Wilkins<[hidden email]>  US: +1  3104915462   IT: +39 3349267680
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

Daniel Burkes-2
>> That was the ticket- adding continuation.reset() to my original code
>> made Jetty happy.  Now, on to figuring out how to make the client
>> side evaluate each mime part separately.
>
> and there in lies the problems of forever responses!
>
> I really think that long polling is better, ie where a complete
> response is always sent and a new request is issues immediately
> afterwards.
>

We're currently using long polling- just investigating alternative  
implementations.

> Even with the multipart response, a packet needs to be sent from the
> client to the server to ack the flushed data.  It might as well have
> the extra 10s of bytes needed to make the next request.
>

Actually, avoiding TCP setup/teardown isn't the reason why forever  
responses are attractive to us.  The biggest problem with long  
polling, at least for an app like ours (realtime chat), is that new  
events occur while the client is disconnected (i.e.- in the teardown/
re-setup process), which complicates the backend implementation.  
However, given that there's apparently no completely cross-browser  
way of doing forever responses (not to mention the problems that  
proxies play with them), it seems more like a dream for now, rather  
than a possible reality.

Thanks for the input!

Best Regards,

Danny

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: I have a dream about continuations...

Greg Wilkins

Daniel,

With most browsers being http/1.1 there is no need for TCP/IP teardown
and setup with long polling.  The TCP/IP connection is maintained and
just a new HTTP request/response is sent over the existing connection.

>From a network point of view, there is very very little difference
between long-polling and forever responses.  Both send framed data.
long polling uses standard HTTP to frame the data, while forever
responses use javascript and 4k of spaces to frame the data.

The work needed to momentarily queue events while waiting for the
next request is almost exactly the work you need to do to queue
events while a chunk of an forever response is being flushed.

Besides, if you use something like bayeux, then we do that work
for you!

cheers


Daniel Burkes wrote:

>>> That was the ticket- adding continuation.reset() to my original code
>>> made Jetty happy.  Now, on to figuring out how to make the client
>>> side evaluate each mime part separately.
>> and there in lies the problems of forever responses!
>>
>> I really think that long polling is better, ie where a complete
>> response is always sent and a new request is issues immediately
>> afterwards.
>>
>
> We're currently using long polling- just investigating alternative  
> implementations.
>
>> Even with the multipart response, a packet needs to be sent from the
>> client to the server to ack the flushed data.  It might as well have
>> the extra 10s of bytes needed to make the next request.
>>
>
> Actually, avoiding TCP setup/teardown isn't the reason why forever  
> responses are attractive to us.  The biggest problem with long  
> polling, at least for an app like ours (realtime chat), is that new  
> events occur while the client is disconnected (i.e.- in the teardown/
> re-setup process), which complicates the backend implementation.  
> However, given that there's apparently no completely cross-browser  
> way of doing forever responses (not to mention the problems that  
> proxies play with them), it seems more like a dream for now, rather  
> than a possible reality.
>
> Thanks for the input!
>
> Best Regards,
>
> Danny
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


--
Greg Wilkins<[hidden email]>                       US:  +1  3104915462
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss