How do I close down a servlet?

[Roger F. Gay]

I have an applet that connects to a servlet via URLConnection method. I have a problem when closing the webpage and then re-entering. There are things initialized in the servlet that must be exited properly to be reused. When simply closing the webpage, they aren't exited properly and the start up initialization fails. I have to restart the server to get it to work again.

I have an input stream to the servlet established and have tried in.close(), to close the input stream onUnload() of the page (it's an html page in an html frame), but that doesn't seem to help.

[David Newton]

Without knowing how your servlet works it's tough to help. From what you've said it sounds as though the servlet/app flow was written completely ignoring that there's just a single instance of a servlet, and it uses members without regard to state.

If you'd describe the flow and/or what's not being handled correctly it'd be easier to help.

[Roger F. Gay]

David Newton wrote:Without knowing how your servlet works it's tough to help. From what you've said it sounds as though the servlet/app flow was written completely ignoring that there's just a single instance of a servlet, and it uses members without regard to state.

If you'd describe the flow and/or what's not being handled correctly it'd be easier to help.

That sounds about right. I designed the sequence to invoke the servlet once when the browser app starts. It uses URLConnection to do that and implements the servlet's doPost() and waits for a response. The doPost() starts a simple server, using a ServerSocket. When I close the web page and re-open it, it tries to repeat this process, and I get a BindException because the ServerSocket is already bound. (If I don't close the browser, and a response is given to the browser, the cycle is complete. A new connection is made, and that works fine.)

My inexperience I suppose. I was expecting the old servlet and related objects to go away once I shut the browser down, and fresh objects to be created when it came back up again. I have a question in another thread about trying to deal directly with the ServerSocket, checking to see if it's bound and handling it on the spot. In this thread, I'm asking whether I can shut everything down nicely when the browser closes. But I suppose, if you can answer the other question - it'll be a solution anyways, no matter what thread it's in. Just trying to keep it friendly by not multiple posting the same question. :)

[David Newton]

The server has *no* idea what's going on on the client side: HTTP is a stateless protocol. I don't recall if there is anything in applets that can do something when it's going away; if there is, you might be able to use that... with the caveat that if, say, the browser simply crashes, it won't happen.

A servlet exists (more or less) for the entire time the web container is running: it never (more or less) goes away.

[Roger F. Gay]

David Newton wrote:The server has *no* idea what's going on on the client side: HTTP is a stateless protocol. I don't recall if there is anything in applets that can do something when it's going away; if there is, you might be able to use that... with the caveat that if, say, the browser simply crashes, it won't happen.

A servlet exists (more or less) for the entire time the web container is running: it never (more or less) goes away.

I've tried closing the input stream in two different ways. That doesn't have any effect. I've searched the Java API a couple of times today looking for url.close() or some such thing, but haven't found anything like that.

[David Newton]

Without more info I'm not sure what else I can tell you... it still sounds like your servlet assumes it'll be recreated, but it won't.

[Roger F. Gay]

David Newton wrote:Without more info I'm not sure what else I can tell you... it still sounds like your servlet assumes it'll be recreated, but it won't.

I tried to break the problem into two different questions, based on different possibilities for handling; one for servlet experts, and one for socket experts. But I've posted a lot of code in response to the other discussion, and I'm now not sure it's better to break it up. https://coderanch.com/t/505686/sockets/java/do-close-bound-socket

[Roger F. Gay]

The question shouldn't be taken as a complicated one, just one that is probably rarely encountered. I encounter it because of very slow responses from the server; which means my app can easily be in the middle of a request when the browser page is closed.

But just think like normal: a web page invokes a servlet. Now, just think; the web page is closed. Then it reopens. I apparently still have a live servlet left over that thinks it's still involved in something. How do I make sure the servlet is shut-down "deleted" when the web page closes.

[Roger F. Gay]

UPDATE: One way I have come to understand this problem is that it's with the persistence of servlets; which are designed to load and persist in order to service many incoming requests from many users. Anyone know if I should have better luck using a normal program object instead of a servlet? I should be able to make a URLConnection to a program object just as easily. I guess that wouldn't persist however, after the web page closes; and everything on the server-side of that process would shut down?

[David Newton]

How do you think web containers work?

I'm not sure why you're using a servlet if all you do with the servlet is open another different connection.

[Roger F. Gay]

David Newton wrote:How do you think web containers work?

I'm not sure why you're using a servlet if all you do with the servlet is open another different connection.

I'm not an expert yet, just someone trying to learn by doing. I'm using a servlet because I chose to. There's no more sophisticated reason for it. It's a server-side component that's connected to the applet. So - it didn't seem like such a wild choice.

If you're asking why I don't just make the other connection directly, it's because the applet can only make a connection to an object on the server that served it. I want a service connection that can be reached at any time by any number of systems / components anywhere. No matter where the contact comes from, this mechanism sends a message to the browser. So, there's one message acceptance point receiving messages from everywhere (the simple socket server) and one connection to the applet to send all messages received on to the web-page (servlet with URLConnection to applet).

[Roger F. Gay]

I was considering a reimplementation today to try using a program object rather than a servlet. Then I ran across this: URLConnection sample program in Java

The URL and URLConnection classes are good enough for simple programs that want to connect to HTTP servers to fetch content. For more complex applications, you'll probably find that you are better off studying the specification of the HTTP protocol and implementing your own wrappers.

On that note, I think I'll just be satisfied for the moment that I have something that works (even though you have to restart Tomcat every time you exit the webpage, before re-entering). I'll hope a network guru decides to contribute to the open-source project. If not, I'll see if I can get back to this later. Fact is, this interface stuff is just extra goodies; not actually part of the main body of code being offered by my open source project. I have to get my attention back on the main stuff to hit my target date for putting the code up.

[Roger F. Gay]

But shouldn't the servlet be notified when a connection to it has been broken? Isn't there a way to create an event handler that responds to the fact - not directly the that web page has been shut down - but that the URLConnection that had been established from the applet has been broken (because the web page closed)?

[David Newton]

You don't make a connection to a svelte (thanks, Android) servlet, you make a connection to a servlet container. And no: as I said, HTTP is stateless. Each request and response is brand new (this is no longer strictly true). As far as the container is concerned each request is shiny and new. That's why we have session cookies or session IDs, otherwise the container wouldn't know it was me making a request as part of a longer-running conversation.

[Roger F. Gay]

OK, it's fixed now. What a kluge! I'll just describe generally. What I was trying to do wouldn't work. OK, I've learned that. I realized however, that I was only using the doPost(), leaving the doGet() open for clean up operations. I confirmed that I was in fact doing the doGet() properly by getting a response, and then put the code in the applet's stop() method. No luck. I did eventually get a change in the error message. That, I think should work, but I don't know why it's not. So ---- I accepted the fact that I would, in some circumstances, get errors, and concentrated on error handling. I had to follow the errors all the way back to the applet, where it was causing the process loop to shut down. So, in handling the error there, I sent a message back to the web-page to reload the page. I also inserted a send message to the socket in the start() method, to confirm that the connection is established, which should put a message "Connection established" in the GUI, but doesn't. I don't know why. Maybe I'll look at that tomorrow. But nonetheless. I can exit the web page and come back, repeat, repeat, repeat, and everything continues to work as it should.