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.