Exit Condition

New York City has an inexcusable population density, and its inhabitants are some of the most self-important existentialists on Earth.

We’ve all got something to do, it’s urgent, we need it accomplished now, and heaven help your sorry butt if you keep us waiting.

So the Service Industry has gotten pretty damn good at getting us our Iced Quad Nonfat Caramel Macchiatos, with Whip!, in due time.

There are some impressive retail strategies for dealing with the masses. I’ve seen:

• One queue feeding into many sales registers
• One queue per register
• One queue, with many associates performing specialized units of work; processing a transaction in phases

Selection of one over the others is generally dependent on the business rules governing the transaction. But there is a common denominator here: The Queue.

Traditionally called “lines” in the United States, the queue represents a holding pattern of service requests until resources become available. This guarantees an even thoroughput.

But hey, I’ve got a new idea! Waiting blows…so I’m going to remove the queue from this equation. Let’s see what happens.

• I arrive at the bank, noticing one teller who is dealing with a customer.
• I approach the counter and give the busy banker my deposit slip and checks.
• The teller alternates between the work she was doing prior to my arrival and the new task I’ve just given her, switching repeatedly.
• The existing customer gives me a dirty look; her work is now being performed at 1/2 speed.
• A new couple walks in, giving the teller 2 requests for a withdrawl.
• Work on Customer 1 is still not done, and is now being performed at 1/4 speed.
• Murder Scene

Maybe I need to rethink this. So its back to the lab, where I send all computational problems to Carlo de Wolf for analysis.

“The issue,” he explains, “is one of Resource Starvation.”

And the EJB3 lead of JBoss kindly continues to draw up reproducible test cases.

Let’s assume a stressing function, where we calculate Pi to 10000 digits 100 times. The idea here is just to get the CPU crunching to simulate some heavy processing.

We’ll invoke this once using traditional IoC/Dependency Injection, and again using EJB3 mechanics. Then we’ll compare the metrics.

//  Make an IoC Container Instance
IocContainer ioc = new IocContainer();
// Install the Calculator class, bound to a key
ioc.install("calculator", CalculatorBean.class);
// Lookup an instance
Calculator calculator = ioc.lookup("calculator", Calculator.class);
// Run the Stressor and print metrics
StressCreator.createStress(calculator);

Neat. Pretty simple. We programatically register a class, grab an instance, and use that instance to churn out our results:

Total Time: 28.21 Seconds
Not Executing: 0.235 Seconds
Invocation Time: 27.814 Seconds

Allright. Because we don’t have a queue here, we spend very little time outside of actual invocation of the test, and the majority of time is spent processing Pi 100 times.

Let’s do another run, using the same Stressor, but using EJB.

// Make an EJB Container
EjbContainer ejbC = new EjbContainer();
// Deploy the EJB
ejbC.deploy(CalculatorBean.class);
// Lookup an EJB Instance
Calculator calculator = (Calculator) new InitialContext().lookup("CalculatorBean/remote");
// Run the Stressor and print metrics
StressCreator.createStress(calculator);

Wonder what we’ll get this time.

From The Caller’s View:
Took 27.691 Seconds
Not Executing: 0.035 Seconds
Invocation Time: 27.541 Seconds

Collected From Inside the EJB Container:
Average Time Waiting on Queue: 13.37449 Seconds
Average Invocation Time: 1.3689 Seconds

From the point of view of a unified caller requesting 100 intensive service calls…looks pretty similar to IoC.

But there’s more here. We’ve now got a hook into the EJB Container, and can clearly see…average execution time of each of the 100 calls is about 1/100 the amount of time spent waiting on an available processor. WHY?

Because with EJB, you get instance pooling for free. When all available instances are taken from the pool, new invocations must queue up. And when you block incoming requests from slowing down your whole system, each individual request can be handled in a reasonable fashion.

The obvious question might be: What’s the damn difference? Both methods take nearly the same amount of time!

Sure. As fantastic as the EJB specification is, it can’t invent CPU cycles on the fly. What it CAN do is provide for incremental return. So the first requests in make it out without having to wait on everyone else in line to complete.

So I can easily draw the following conclusions, assuming 100 concurrent requests:

• At WORST, the last service request in EJB will return at the same time as the full IoC return.
• At BEST, EJB will begin to return requests in under 2 seconds, and these clients may be on their way.
• You will not have any N number of Threads spreading your processor too thin.
• If you’re allowing an Enterprise System to spawn a Thread for each request, you should work for McDonald’s.

On second thought, I revoke my last point. Even pre-teens working the McDonald’s drive-through make each car wait its turn.

S,
ALR