Ah ok thank you for very concise answer. am chasing a pipe dream I guess.
Maybe there is another way to get this kind of benefit.

Thanks again for your answer.

Owen Rubel

On Sat, Aug 12, 2017 at 1:19 AM, Mark Thomas <ma...@apache.org> wrote:

> On 12/08/17 06:00, Christopher Schultz wrote:
> > Owen,
> >
> > Please do not top-post. I have re-ordered your post to be bottom-post.
> >
> > On 8/11/17 10:12 PM, Owen Rubel wrote:
> >> On Fri, Aug 11, 2017 at 5:58 PM, <christop...@baus.net> wrote:
> >
> >>>> Hi All,
> >>>>
> >>>> I'm looking for a way (or a tool) in Tomcat to associate
> >>>> threads with endpoints.
> >>>
> >>> It isn't clear to me why this would be necessary. Threads should
> >>> be allocated on demand to individual requests. If one route sees
> >>> more traffic, then it should automatically be allocated more
> >>> threads. This could starve some requests if the maximum number of
> >>> threads had been allocated to a lessor used route, while
> >>> available threads went unused for more commonly used route.
> >
> >> Absolutely but it could ramp up more threads as needed.
> >
> >> I base the logic on neuron and neuralTransmitters. When neurons
> >> talk to each other, they send back neural transmitters to enforce
> >> that pathway.
> >
> >> If we could do the same through threads by adding additional
> >> threads for endpoints that receive more traffic vs those which do
> >> not, it would enforce better and faster communication on those
> >> paths.> The current way Tomcat does it is not dynamic and it just
> >> applies to ALL pathways equally which is not efficient.
> > How would this improve efficiency at all?
> >
> > There is nothing inherently "showy" or "edity" about a particular
> > thread; each request-processing thread is indistinguishable from any
> > other. I don't believe there is a way to improve the situation even if
> > "per-endpoint" (whatever that would mean) threads were a possibility.
> >
> > What would you attach to a thread that would make it any better at
> > editing records? Or deleting them?
> And I'll add that the whole original proposal ignores a number of rather
> fundamental points about how Servlet containers (and web servers in
> general) work. To name a few:
> - Until the request has been parsed (which requires a thread) Tomcat
> doesn't know which Servlet (endpoint) the request is destined for.
> Switching processing to a different thread at that point would add
> significant overhead for no benefit.
> - Even after parsing, the actual Servlet that processes the request (if
> any) can change during processing (e.g. a Filter that conditionally
> forwards to a different Servlet, authentication, etc.)
> There is nothing about a endpoint specific thread that would allow it to
> process a request more efficiently than a general thread.
> Any per-endpoint thread-pool solution will require the additional
> overhead to switch processing from the general parsing thread to the
> endpoint specific thread. This additional cost comes with zero benefits
> hence it will always be less efficient.
> In short, there is no way pre-allocating threads to particular endpoints
> can improve performance compared to just adding the same number of
> additional threads to the general thread pool.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to