tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "deepak shripat mane" <>
Subject Re: Scheduling and queue management under Coyote
Date Wed, 24 Nov 2004 04:18:03 GMT
Hello Simian

Can u tell me Your OS platoform. If u r using windows then try to integrate your IIS Server
. Did u use any priority queue conceptin ur program. if so then u can write a special algorithm,s

Can u send me sample code


On Wed, 24 Nov 2004 Simian Vector wrote :
>Hiyo.  We're a large company investigating integrating Tomcat into our
>production environment.  There is one feature that exists in our
>current (internally built) servlet container that does not seem to
>exist in Tomcat, and we're wondering if it's possible to emulate the
>behavior or spearhead development.
>We have a custom template language and a servlet that compiles and
>executes the templates.  Under our current system, each template is
>given its own queue and incoming requests are handed off to the
>appropriate queue, from which dedicated threads pull off the request
>and execute the transaction.  The upshot of this is that faster
>templates are able to execute more or less independently of slower
>templates.  A poorly-performing service can't saturate the thread pool
>and block out other services, but will instead run into its own queue
>size cap and toss error pages back.
>Judging from a quick overview of the Coyote/Catalina source, it looks
>like that is not possible under Tomcat, since a single thread manages
>the transaction from end to end and that thread comes from a single
>So, a few questions.
>1.  Are we wrong and there is actually a way to configure this
>behavior in Tomcat?
>2.  If not, is there any interest in us developing a solution and
>having it integrated into the Catalina base?
>We're looking at either a re-implementation of transaction queues and
>building a custom Connector that hands off transactions appropriately;
>or a more simple solution of allowing multiple worker thread pools to
>be setup, and then allowing particular request paths to map to
>particular thread pools via server.xml configuration.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message