Tomcat's primary intention is
not to enqueue incoming requests, but to immediately transfer them to processing threads. Which, I think is where the confusion lies.
The actual incoming HTTP request stream is compiled to form an Http[
Servlet]Request Implementation object (as defined by Tomcat in conformance with the
J2EE API), which is augmented by various environmental considerations, including the user's Session (if it exists) and paired with an Http[Servlet]Response object in order to facilitate the application's processing of the request. A very crude description I fear, but mostly accurate.
Tomcat keeps a pool of threads to hand incoming requests to. Now in actual fact, I do believe that once that pool is exhausted, a limited (configurable) number of requests can be queued, but once that resource reaches capacity, Tomcat will simply bounce further requests.
Apache/jakarta contains a rich set of component projects including resource pooling components. I know they're used by Tomcat's default DB connection pooler (which is itself an Apache commons component - DBCP). They
may also be the plugin queueing mechanism for Tomcat, although I'd have to go back and look at the source code myself.
Tomcat is itself built out of components, so I'd expect any queuing to be done in either the Host or Engine subsystems (probably Engine), where it would then pipe requests through the Valve chains and eventually into user code.
I don't know if this is going to help - especially since I may be remembering some things incorrectly, but that's the approach I would use in trying to track down and replace whatever queueing mechanisms Tomcat actually does use.