The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:If your JSP is calling a SOAP service, first Bear will growl at you for putting application logic on a JSP instead of in a servlet
Tim Holloway wrote:First, there is no ongoing conversation between client and JSP to be closed.
In HTTP, the client connects to the server and sends the HTTP request as a unit. Only when the entire request has been received by the server does the server act on it.
The server parses the request URL and determines which webapp to send the request to and which servet/JSP to send the request to. JSPs get compiled into servlets, so the same actions apply to both JSPs and servlets.
The servlet (JSP) is not an independently-running program nor does it directly communicate with the network. Instead the webapp server pulls a Thread from a pool and dispatches that thread to the servlet(JSP).
In absolutely no case should the servlet/JSP terminate that thread
Nor should the servlet/JSP attempt to spawn threads of its own. If you do either of these things, you will destabilize the webapp server and it may eventually crash, taking down all its applications at unpredictable times.
When the client sends the request to the server, it opens a reply port for the server to send the response back to. The client will hold that port for a certain (cllent-defined) interval. If no response is received by the time that the interval expires, it will time out, close, and the browser will display an error message. If the server attempts to send a response back from the JSP request, but the client is not listening, the response will be discarded.
So it doesn't matter how many clients there are as far as processing threads go. Each thread is associated with one and only one client. If there aren't enough free threads in the server thread pool, further requests will be queued until a thread becomes available. If the thread queue also gets full, the server will reject any further incoming requests until the backlog is relieved.
If your JSP is calling a SOAP service, first Bear will growl at you for putting application logic on a JSP instead of in a servlet, but secondly, the JSP/servlet worker thread will hang until the response has either been received or timed out. So if you know that the SOAP service will routinely take a lot of time, you need to set up an alternative means of processing it. Because while the thread won't die, it also won't be available for any other client requests, and the server will start backing up like I just described.
Bear Bibeault wrote:See this article for an article on properly structuring Java web applications.
Don't get me started about those stupid light bulbs. |