Hash: SHA256


On 8/12/17 11:21 AM, Owen Rubel wrote:
> 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.

> 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.
The answer is caching, and that can be done at many levels, but the
thread-level makes the least sense due to the reasons Mark outlined abov

- -chris
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to