I understand that it's considered bad design to use a normal, threaded webserver (e.g., Apache) for AJAX long polling…but I don't really understand why.
Is it because each longpolling request takes significantly more time than a normal one would (thus tying up the processor)? And if that's the case, do threads really take that much overhead that they cannot remain idle for awhile before use?
Just to clarify, AJAX polling is when client-side javascript makes an AJAX request that isn't fulfilled immediately. Instead, the server waits until it wants to push a reply to the client and then uses the already-open AJAX context to do so. (right?)
On a web server that handles each connection its own thread, that open connection is going to cause one thread to be created for each client on the web site. The thread will stay running until the client closes the connection. When I say "running", that just means that the thread exists and is taking up server resources; it could be idling in a sleep() or wait() function. But it still consumes far more system resources than would be used in an event-based server.
It is not that you are tying up the processor, but you are blocking a connection and a thread of the thread pool. The server has then to be configured with a much larger thread pool.
If your application tries to rival facebook you then have a major issue on your hands, if it is an internal application in a SME for ordering lunch, no one will be hurt.
This is not really a cut and dried question since it has various factors that can affect the answer.
For example, are you using yaws (a webserver written in Erlang)? Then it wouldn't really be an issue, except that you are tying up ports on the webserver, but threads are not an issue.
Are you using Java NewIO API, so each connection doesn't take a dedicated thread, then it won't be an issue for threads.
But, if you are tying up resources needlessly, regardless of what you are doing, then that is bad. For example, if you keep a database connection open, do some major processing, then write back, that is also bad design.
Keep resources for only as long as you need them.
If you are going to do some processing that takes a sizeable amount of time then you may want to look at a more asynchronous solution.
For example, give some unique number that the user can use to check if their request is done, so they can shut down their computer, or just check it whenever they want, without worrying about losing anything.