Hash: SHA256


On 8/12/17 12:47 PM, Owen Rubel wrote:
> On Sat, Aug 12, 2017 at 9:36 AM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> Owen,
> 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 e.
> -chris
>> ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> Well caching is: - related to resource not communication - is a one
> time thing and has to have a version check every time.
> What I am talking about is something that improves communication as
> we notice that communication channel needing more resources. Not
> caching what is communicated... improving the CHANNEL for
> communicating the resource (whatever it may be).
> But like you said, this is not something that is doable so I'll
> look elsewhere. Thanks again. :)

If you want to improve communication efficiency, I think that HTTP
isn't the protocol for you. Perhaps Websocket?

- -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