The Artima Developer Community
Sponsored Link

Articles Forum
Continuations in Java

7 replies on 1 page. Most recent reply: Sep 21, 2007 12:22 PM by Mike Killing

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 7 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Continuations in Java Posted: Mar 1, 2007 8:50 PM
Reply to this message Reply
Advertisement
In this interview, Geert Bevin explained that the main use-case for continuations is in simplifying the implementation of complex workflows. Do you think that the added APIs and tools used by continuations are worth the simplified programming style they introduce?

http://www.artima.com/lejava/articles/continuations.html

What do you think of continuations? Do you want them? What would you do with them if you had them?


Sven Meier

Posts: 3
Nickname: svenmeier
Registered: May, 2003

Re: Continuations in Java Posted: Mar 2, 2007 4:12 AM
Reply to this message Reply
Gilad has a nice post on this:

http://blogs.sun.com/gbracha/entry/will_continuations_continue

Cite:
"This UI is a regression to the days of time sharing, before the advent of the personal computer and GUIs. It’s forced upon you by HTTP; you’d never design a true GUI application to behave this way."

I would like to add:
How many times do you encounter a continuations-styled flow in a desktop application? I'd say the lesser the better.

In Eclipse I face a modal dialog (something similar from the user perspective) once or twice a day - for my taste that's enough.

Sven Meier

Posts: 3
Nickname: svenmeier
Registered: May, 2003

Re: Continuations in Java Posted: Mar 2, 2007 4:14 AM
Reply to this message Reply
I don't want to imply that continuations are not useful for other things besides user interfaces.

Lars Schneider

Posts: 1
Nickname: lysosterol
Registered: Mar, 2007

Re: Continuations in Java Posted: Mar 2, 2007 6:34 AM
Reply to this message Reply
If you're interested in continuations for web application
you should have a look at siscweb http://sourceforge.net/projects/siscweb/. As it is based on sisc (a scheme interpreter for the java vm) the continuation part is nicely intergated in the host language.

david m

Posts: 4
Nickname: davidm
Registered: May, 2006

Re: Continuations in Java Posted: Mar 2, 2007 11:58 AM
Reply to this message Reply
Here is another implementation

http://rhinoinspring.sourceforge.net/

using Rhino Javascript continuations and Spring Web MVC, therefore most interesting to Spring users who view Javascript is a good dynamic counterpart to Java.

With discussion here: http://www.theserverside.com/news/thread.tss?thread_id=44389#228168

Pete Kirkham

Posts: 2
Nickname: machineelf
Registered: Aug, 2005

Re: Continuations in Java Posted: Mar 4, 2007 8:16 AM
Reply to this message Reply
> Gilad has a nice post on this:
> Cite:
> "This UI is a regression to the days of time sharing,
> before the advent of the personal computer and GUIs. It’s
> forced upon you by HTTP; you’d never design a true GUI
> application to behave this way."

As discussed in this follow up, and elsewhere, you wouldn't design a web application to behave this way either; it's just a consequence of lazy programmers stuffing everything into the session -
http://www.megginson.com/blogs/quoderat/2006/05/20/continuations-contd/

http://rifers.org/wiki/display/RIFE/Acceptable+session+support
# RIFE transfers everything by default through the client-side and makes the URL or HTML form drive the application.

So it seems that it'll make doing the right thing easier than doing the wrong thing.


Pete

Tim Vernum

Posts: 58
Nickname: tpv
Registered: Dec, 2002

Continuations in Jetty Posted: Mar 4, 2007 10:52 PM
Reply to this message Reply
As Geert says, Jetty's continuations are fairly minimalist.

Because Java NIO doesn't need to allocate a thread for each socket, you can take advantage of that to avoid needing to have a thread allocated to each HTTP request as it comes in.

There are 2 main uses cases for that.

#1, AJAX style processing, where the client is polling the server for updates. There are 3 design strategies you can employ here
a) Block at the server. The request hits the servlet (or some other HTTP artefact) and the servlet blocks until there is an update to return. That takes relatively little CPU usage, but you need to have a thread available for each HTTP client that is currently connected. Given the relatively low number of threads that most JVMs can handle, your server scalability tends to constrained not by CPU or Memory, but by thread count.
b) Make frequent HTTP requests. The client requests an update, the server returns "no change", and then the client requests again a second or so later. You end up with a lot of network traffic, and you still quite a number of concurrent HTTP requests (and, therefore, threads), but not as many as in (a).
c) You separate the connection between an HTTP connection and a thread. If you can maintain the HTTP state, but not have a thread permanently allocated to it, you keep network traffic to a minimum, and you can also scale out to accepting more connections than you have threads for. Jetty uses a continuation mechanism to support this model.

The other case for separating HTTP connections and threads, is when there is another resource involved. In reality this is just a more general case of #1 - you want to minimise the extent to which a deficiency in 1 resource can cause a ripple effect in another resource.
e.g. Often, if your HTTP request needs to get a database connection and the connection pool is empty, the request will block for some period of time. The problem is that the blocking request will (normally) consume a thread while it it blocking. So now you have 2 problems, you have a database pool with high contention, and you have a thread pool which is being locked up with waiting threads.
If you can free up threads when the DB pool blocks, you can keep that problem from expanding to become a bigger problem.

Jetty implements this using exceptions. If the jetty handler throws a RetryException then the server will re-queue the HTTP request and return the thread to the thread-pool. After a defined period of time the HTTP request will be re-issued to the handler.

Greg and I have each written blog entries on it at:
http://blogs.webtide.com/gregw/2006/10/18/1161127500000.html
http://blogs.webtide.com/gregw/2006/12/07/1165517549286.html
and
http://blog.adjective.org/post/2006/10/19/A-Continuation-of-another

Mike Killing

Posts: 2
Nickname: junilica
Registered: Sep, 2007

Re: Continuations in Java Posted: Sep 21, 2007 12:22 PM
Reply to this message Reply
I think that would be useful since I have tried to save a thread that had a reference to a site I needed that time, working capital http://www.working-capital-loan.com, I think. By the way, do you happen to know where it is, the thread, that is?

Flat View: This topic has 7 replies on 1 page
Topic: Subscribing Template Classes with Object Factories in C++ Previous Topic   Next Topic Topic: BoostCon'07 Trip Report


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us