On Sat, Aug 12, 2017 at 3:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Owen,
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmPfYEACgkQHPApP6U8
> pFivQg//RACaNIne3hC5nlpoQATZ1qDl6zJLrGD9qSyooRkAeQxmOS2AlIZgrdzP
> c69Ze3hIRSaxGW0ecdm0weRINimtKqjJqGsEa6AOWsWyC6KUMk6L63cLIvmoNl7t
> 7kUK/YeOfD4dVnHBcy4QeOY0svVHP9CLPT7wnNv4qH02+ZzB3CtEXu5gOFmUg7Zk
> H7R8tKKce0RtNWtf2UDrlYy2ZKrpTsp5G4KI8p3hmKeIxY1UyItNbxRTL53OMDSU
> 9negiFcHGxf8JKQPq+Uqh08Bj+ZGlY4tdlhmY+MWNEJnu4DQPlx67QfHGlbmz1Cc
> Eegnb2Rc5DEBvnaj8Ow7vgjTAosng3BQ2dLJR9m+nfzBpGfsAFbMPDp5LEsPQH3P
> Erw/OY9gUt41jqqOq0K5uiB//tu0KMfeR4XPGZ0avq12lv2zYfbp6oDIidFsAPpd
> TiZOV1GsJhLVe61nG28+QTDxBuzWuaoBqPmVmNb+vT3DC37VbRG1v/9dnX3mn373
> dB87iKnb8VGTbAP2loTV0OsyBtpn8ruc3WNURHgAgxKADmettG6c47WxDN2HwPpH
> L6avgIkiGhS/3y7quDNo8JD08VQpuMtxiVsdt5xwsC6fdHtkNgbSG/2qCAgKQcKQ
> DNiadO15ASuTm59e3Tqmk6vVhtMvsc+cWeq6T5x5tXyXPSP2VpA=
> =sDX7
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Well I'll try not to take offense at that...heh. You may not be aware of my
contributions to date. :)

But again, appreciate the feedback. So thank you.

Reply via email to