Here is some more documentation on Jetty Continuations. It appears as
though their work will be in a future version of the Servlet 3 spec.

I am not an expert at how Continuations are working, though I have
done some Servlet programming in my day. As I understand it there is
some sort of HTTPSession object that stores information enough to
marry up a client request with a server repository of meta-data about
that session. It would seem Continuations are solving a problem that
doesn't exist in the RPG + Apache/IBMi world (I don't feel like I can
call it RPG CGI anymore because that name doesn't really fit).

For example, we don't store multiple session threads but instead just
retain the previous request's "global" resources (i.e. global
variables in *PGM/*SRVPGM objects, open data paths, etc). Am I
reading that right? So it isn't like they are embarking on something
revolutionary and new - they are just fixing the error of their ways.
Somebody correct me if I am wrong.

Aaron Bartell

On Thu, Oct 7, 2010 at 1:21 PM, Thorbjoern Ravn Andersen
<ravn@xxxxxxxxxx> wrote:
 Den 07/10/10 19.42, Aaron Bartell skrev:
This is an interesting concept, but how do they do that without
requiring some sort of asynchronous approach where the server
communicates back with the client in a new request? (basically
switching roles)

Does it require special code on the client?  Does it require the
client to poll the server?
It is possible with the non-blocking NIO libraries which was introduced
a while back.  I am not familiar with the details, but the Jetty
implementors called it Continuations when doing the work for Jetty 6.

There is a write-up at

  Thorbjørn Ravn Andersen  " Tubular Bells!"

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].