My apologies if this is too vague to warrant consideration.
In the recent past I managed a naked port, a Selector, a
ThreadPoolExecutor and friends (and it worked well enough...) but a dear
and knowledgeable friend suggested embedding tomcat and using http.[3]
I have that working, one request at a time.
Now to get to "production level": I have two distinct types of
requests which might be problematic: one is rather large[1] and the
other rather prolific[2]. Both types are handled by the same servlet.
The data structure is identical, just much less in case[2].
Is it advisable, practical to (re)establish a ThreadPoolExecutor, queue
etc as a tomcat accessible "Resource" with JDNI lookup, and have my
servlet pass the work off to the Executor's queue?
Any pointers appreciated,
rjs
[1] Comprised of a data block which occasionally has exceeded java
max array length, gzipped streams helped a lot. There are few of
these requests (22 per project). They last days and can "collide"
in terms of when they finish, though by and large they naturally
spread themselves out.
[2] Given infinite EC2 capacity there would be tens of thousands of
jobs started at once. Realistic AWS capacity constraints limit this
to hundreds of instances from a queue of thousands. The duration of
any instance varies from hours to days. But the payload is simple,
under 5K bytes.
[3] I'm not entirely confident the original implementation handled
all "requests" properly.
