On Sat, Aug 12, 2017 at 9:36 AM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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 > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmPLngACgkQHPApP6U8 > pFisbw//aiIg0vGmmlm4T/xoEbAKblKf6Qn9zmDzbLY9IbIG7MdsMcuV9hnsasEp > iaZs3ROTy3BvWKGoyIGThtRsBPSFmb1H/XuKs4bqxgdRNgcbxEbjkH+1wZCx76Aq > aqdIiCFdWvkOll4EqC4UYjNXCMkMBoTGN4GTxGmB8arujOyiC1KVPLY+wiRtXusF > BrV3n9G+wN7Qq+rHIvgct1J29xTnPwQWhcdTrR5+IXn7vuNhEe9yxlKyJh4N6Pkt > TW8ZlZfUgPnAXYZFvb0UfRK43cOCP4HsgncvIDjnnRJVTnaqRKBuRE4ZVYJG91SN > CHUCYAmCR/rUZcOO3VJZ0dE7OEkrtcs6tmRT7j0qfS2qxbAb6YuW5xNYrCTgWKyD > 6bUCQsKzcChV4mQPVDjXO/yv1t3dpXeMB+44KwCVB3bFPTediwISzTxInCSd/Kdu > I+57Rcrclto8S3+GRsUPRG3dwsNMYMIxHpuzj/LYzLNdoANI8vM5NntYdQ4cwEFM > H23i54m00WQ5RLuRJGzker+T5H0NvGlVwFQnqO9kCkA57o1Gi+vk34UuNPVLsqHx > sKq6Eb4s3MeslZBPHhJWYXGPx226+T6sEXO1y2UZ9GuWYzfI3MF6/xcFOI2/W3id > kYZEnR3R1Xes7GzsSLuCXVRDQco3GhXvSiyLvYC9xwgIsjnM61Q= > =Q/vf > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > I think I understand the confusion. The old API pattern binds communication/business logic in centralized architectures causing an architectural cross cutting concern in distributed architectures (ie proxy, api server, message queue, etc). To fix this you have to unbind communication from business logic so that you can share I/O (request/response) without duplication and entanglement. You may be under and assumption that the endpoint is CONTROLLER/BUSINESS LOGIC; this is false. It is communication layer as communication layer can callback to iteself. Communication layer can forward, redirect, talks to service/business logic to gather resource, etc (as it doesn't even have to return resource) but the communication layer in the API service is where the endpoint exists. What I am trying to do is atomically assign resources to endpoints as traffic increases/decreases. *In an embedded tomcat instance, I thought this would be possible.*
