>From my point of view, focusing on protocols is not necessarily the only reason to want thread pools. I'm not all that familiar with AS 4 yet, so maybe I'm being dense here... keep that in mind. :)
The reason thread pools would be interesting to me personally is to be able to control quality of service better. For example, I may want a pool of 5 threads to handle search engine spidering requests, and a pool of 5 threads to handle PHP requests, 5 threads to handle a particular application that uses a different database, 5 threads to handle CGI requests, 10 threads to TCL requests, 5 to handle image serving (fastpath), 5 to handle all other requests. I'd want to dispatch the requests to the various thread pools myself, using TCL code. The protocol and communication method (TCP vs UDP) part are all the same here - HTTP. Perhaps this can all be done today with AS 4 using multiple IP addresses - I dunno. However, sometimes it would be useful to have the pool functionality with one IP address. If a search engine decides to aggressively index your site, they have to do it on the main IP address. Being able to give them a different class of service, ie, a different thread pool, would be useful. We've already done a similar thing, by setting up multiple AS instances. But it would have been easier in many cases to set it up with thread pools. Much less code on our end to change. A way to accomplish the same thing today is by putting an intelligent switch/cache/proxy device in front of multiple servers, and having it route certain kinds of requests to certain servers. The problem from my point of view is: - the switch is another device to manage - it's an extra $5000+ - it's often a proprietary solution - if you look at client IP addresses, you have IP address issues to deal with, or have to set up some fancy routing, or have to modify your code to get the true peer address from a made-up header - you have to learn how to use the device's routing rules instead of making rules yourself, with TCL - hit logging will probably work differently; another difference to handle Another advantage to using thread pools in this application is that it may help a site be less vulnerable to DOS attacks. If a site is running 3rd party bulletin board software for example, and someone decides to run an attack against it, it may still kill that the board service/thread pool, but the other services running on the same server instance would not be unaffected. Without this partitioning, the attack might use all of the threads and kill the site. Maybe the thread pools could also have priorities too. So I could make dispatching decisions based on the current request load, like, "If there are more than 5 threads active in the main pool, hold off executing any new requests in the bulletin board pool, ie, queue the request, but don't let it execute. In an ideal world, there would always be enough resource to do everything, but in the real world, there are sometimes momentary resource shortages that cause things to get slow. If something is going to be slow, I'd rather it be a non-essential service like a bulletin board rather than the threads generating our main pages. Is this something critical I can't live without? No. But it seems useful. Jim > I definitely vote for a). I think AS has a very > powerful framework that can be used outside of http. > > --- Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > > On Tuesday 17 August 2004 10:32, Zoran Vasiljevic > > wrote: > > > Hi! > > > > > > I would like to start a discussion which will > > eventually lead > > > to one of the two proposals listed below (one from > > Vlad Seryakov > > > and the other from Stephen Deasey) included in the > > core-server > > > distribution. > > > > Eh... wrong turn again... > > By "start a discussion", I really expected the > > people to > > respond with: > > > > a. YES, I like AS to be more powerful > > multiprotocol > > server instead of being a powerful http-server > > only. > > And, I like proposal X better than Y because of > > Z. > > > > b. NO, I do not need AS doing anything else than > > http > > and am perfectly happy with status-quo now. > > Just > > forget the whole thing. > > > > I apologize for not being more precise. > > > > If a. turns out to be everbody's darling, then there > > are > > two excellent proposals for making this work. If > > somebody > > has a better solution, lets see this as RFE. Then, > > get a > > couple of (knowledgeable) people vote in democratic > > way > > about what's the better solution. I think there is a > > AOLSERVER-DEVEL (or such) list where deeper > > technical > > issues can be discussed in a smaller audience. > > > > If b. well, than it is clear. We just leave it > > as-is. > > > > Can we agree on this? > > > > Zoran > > > > > > -- > > AOLserver - http://www.aolserver.com/ > > > > To Remove yourself from this list, simply send an > > email to <[EMAIL PROTECTED]> with the > > body of "SIGNOFF AOLSERVER" in the email message. > > You can leave the Subject: field of your email > > blank. > > > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with > the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field > of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
