JSP and infinite loops...

[iago]

If a jsp (or even a servlet) is in an infinite loop, and the client terminates the connection, will it automatically kill the thread, or will the thread live on taking up resources till I restart the server?

[CrAzY]

inf Loops Will Crash you, won't it?

[iago]

No, I don't think so.. I've written programs that count to a million, and that didn't crash me

What I'm thinking is, if there's an infinte loop and the client disconnects, an out.print will probably throw an exception which would indicate that it's over.

But until I'm sure of that, I'm not touching this

[iago]

I just found this:

Knowing When No One's Listening

Sometimes clients hang up on servlets. Sure, it s rude, but it happens. Sometimes the client makes a mistake and goes to the wrong page. Sometimes the servlet takes too long to respond. Remember, all the while a servlet is preparing its response, the user is being tempted by the browser s big, glowing Stop button that is just begging to be pushed. You may be wondering, just what happens to the servlet once that button is pushed?

Unfortunately, a servlet is not given any immediate indication that the user has pressed the Stop button there is no interrupt that tells it to stop processing. The servlet discovers the client has stopped the request only when it tries to send output to the nonexistent client, at which point an error condition occurs.

A servlet that sends information using a ServletOutputStream sees an IOException when it tries to write output. For servers that buffer their output, the IOException is thrown when the buffer fills up and its contents are flushed.

So it seems like it'll automatically end, eventually, so that's a plus.

<edit>
"I have found some more writing at the end of the parchment!" -Simpsons

It's important to note that a server is not required to throw an IOException or set the error flag of the PrinWriter after the client disconnects. A server may elect to let the response run to completion with its output ignored. Generally this does not cause a problem, but it does mean that a servlet running inside such a server should always have a set end point and should not be written to continuously loop until the user hits Stop.

[Skywing]

That sounds fairly inconsistant.  So much for Java being ultra-portable...

[iago]

That sounds fairly inconsistant.  So much for Java being ultra-portable...

As of the time of this book I'm reading ('01, I think) the servlet API has become much more standardized

[Adron]

Look for a method to ask the server if the client is still connected? With buffering, you won't notice until you're done unless there's a way to manually poll for connected client.

[iago]

The only way I could think of is to make an applet and use RMI or a direct socket connection (applets can make a socket connection to *only* their source server).


Incidentally, to respond to skywing again, the reason for the divergence in Servlet implementations is mainly because each web server implemented it in their own, similar way, not in a totally standard way.  Probably, modern ones are standardized, but this book is '98, when IE and NS 4.0 were the newest browsers.