Re: How do i handle long-running background tasks in J2EE?
On Wed, 15 Sep 2010, Arne Vajh?j wrote:
On 15-09-2010 13:54, markspace wrote:
I don't know, this is all made up, but...
On 9/15/2010 10:36 AM, Tom Anderson wrote:
1. User is on the order review page and clicks 'confirm'
2. User goes quickly to a 'were processing ur order lol' page, and waits
for it to sponteneously occur that ...
3. User arrives at the order confirmation page
I would have page number 2 switch to "long poll" right now to determine
when page 3 is ready. I other words, you have two URLs:
2a. www.mysite.com/lol_processing
2b. www.mysite.com/process_card?n=1234455667890
Page 2a loads, then tries to load page 2b. When it get a response, then
it loads the confirmation page, possibly using some sort of key returned
by 2b.
This is just:
A. The simplest thing I could think of.
B. Doesn't need to use any thread manipulation. 2b can take as long as
it likes.
C. Doesn't bake any UI rules into the servlets. Each URL is an
independent task. The UI itself takes care of timing/presentation.
D. System testing should be easier as a result.
Again, no special experience, just trying to simplify the interaction.
Interesting! It would indeed make things simpler.
My only concern would be:
But for a busy site and a pre-"servlet 3.0" container it will
either create a lot of threads or give errors.
If it ties up each thread for ten seconds, and we have n requests per
second, then we'll need 10n threads to handle them. I don't have our
statistics to hand, but off the top of my head, i think we handled several
thousand checkouts per hour on the busiest day of last year; that
corresponds, very roughly, to single-figure checkouts per second, which
would mean <100 threads needed to support this model. The application will
probably be split over a few instances, so we're looking at, i would
think, 10-50 threads per instance. That should actually be perfectly
doable. If i remember wrong and it was tens of thousands, then it's a
matter of 100-500 threads; that might be more of a challenge, but in that
case, we ought to have more or beefier boxes to handle the load.
I don't know whether there would be other consequences of having such
long-runnning threads. Timeouts?
I do know that i will face very strong resistance from the colleague with
whom i'm pairing on this to doing it this way: one of his key motivations
in this work has been to avoid long-running request threads, apparently
based on prior experience where they caused a lot of trouble.
Arne: how does servlet 3.0 change this? I'm afraid i know nothing about
it.
tom
--
everything is temporary