Registering callback

Is it possible to register a "callback" function inside servlet which is then called when http connection is terminated. I a developing a servlet which do heavy processing which takes a time. I would like to have servlet stop and exit if user terminates connection.
Right now servlet is active (thread is alive) until it finishes and then generated output is discarded.
TIA
Haris

Hi,

Interesting question....

On the client side I would try to do one of the following
1) have a button which is the first thing that loads on the page, and that is a close button, which will then submit back to the same servlet
2) Use javascript to capture the window close event and probably submit back to the serlet on that, or beriefly open another window to do the submission.

Neither of those are really the servlet bit of it though. What I suggest though is that you declare a static member variable boolean that is you processing switch. Then this variable can be checked at frequent intervals in your processing algorithm, and exit it if the processing is switched off.

I'll do a little walk through

1) your httprequest comes in to do you massive processing task.
2) you set processing to true
3) send your close mechanism to the browser (lets say for arguement the close button).
4) process away
5) if the close button is clicked you capture this in your servlet, and set your processing to false. This alerts the thread thats running the massive processing task to stop the loop next time it checks if it needs to continue processing

Is this clear? I could do some example code if this isn't detailed enough

Oscagne

Thanks for thoughts, but I need to keep things simple on client side. I found myself often impatient and just hit reload if the response text did not came soon enough, not to talk about other users.
The ideal situation would be if servlet could have knowledge of TCP socket assigned to the conneciton . "The callback" would be to the socket disconnect.
Haris

Hi,

I haven't a clue whether this'd work, but why don't you try the following....

Instead of getting a printwriter for the servlet output why not get the output stream instead.

Then at frequent itervals write a space (assuming your outputing HTML then this has no visible effects) to the output stream, make sure you wrap a try catch (for IOException) around this, and if you get this exception then exit the algorithm

Any good?

Oscagne

Hi Oscagne
I tried your idea and it did not work.
print;flush to the ServletOutputSteam did not generate any exception. I made servlet to post status on the console screen and I could see it processing loop. After I disconnected browser nothing happened. Servlet itself just waited to finish processing and then normally exited.
Any new ideas?
I'll keep investigating
Thanks,
Haris

Hi,

Ok, I've thought of a few things

1) I thought that the idea for the outputstream was only a vague possibility, but I just saw the IOException of outputstream and thought it might work...2 things about this before you abandon it
a) you might want to use the outputstream methods (write (byte [])) instead, as they might behave differently (i.e. not be quite as protected)
b) Try sending more stuff to the client when you do your checking, as although the flush is done, this doesn't guarentee it's gone. I think all it does is send it to the TCP/IP layer, which can behave how it wants... It might hang around waiting for a packet to be filled. So maybe you should try sending a lot of blanks down it...I recommend at least 2000 a byte [], but the more the better.

2) Another way could be to get an applet on the client side that can periodically be contacted to find out if the client is available. This wouldn't be too tricky to do I shouldn't think.

3) The javascript (although I hate the stuff with a passion), is probably still possible, you just have to catch the window close event and contact the server in some way when it occurs.

4) You could get the page being refreshed on a regular basis, which would keep the server informed that it was still there, and cancel the algorithm after a predetermined time out.

5) Periodically you could send javascript function calls to the browser to communicate back to the server (similar to 4), but this wouldn't be in timed intervals, only at the times when the check is being done.

Regarding 4 and 5...What sort of connection will there be betwen client and browser... is it reliable? (i.e. is it guarenteed that you can get end to end and back again communication in under 10 seconds for example)

If I had to choose I'd say that the applet in the browser was probably the best way to do it.

I'm quite tempted to give some of these a go to see which one is best, cos it's quite an intruiging idea, but at this very moment I haven't got the time.

Some other areas that I've had ideas in (but don't know to much about....yet) are server side push (think this doesn't work in IE though), DHTML, using a different mechanism (i.e. not using a servlet, but using a direct socket connection..which could work well I think), and a few other ideas, but they're kinda just floating about at the moment, so I'll have a think about them

Hope that helps

Oscagne

Hi ,
I found something at JDC discussion. Two solution offered: One the same as yours with Outout stream, the other one to use PrinterWriter and PrinterWriter.checkError function after write is done.
Neither worked in my case (it could be server implementation - I am trying to make things work on Domino 5.08)
Inspecting the source codefor checkError all it does is
to flush then check if output stream is null. If it is returns true.
Maybe it waits for packet to fills but sending a lot of spaces may use my bndwidth in case of number of connection. I'll try to see how things works with Webspehere.
Thanks

Hi,

Right curiosity beat me. I coded a little example of the outputstream version and ran it under tomcat, with IE 6 as the broswer and on WinXP.

It worked perfectly, and didn't work just on browser closure, but also on browser stops and refreshes.

Hope you get it working, otherwise give the forum a shout and I'll post my code

If you were worried about bandwith I wouldn't be, as 2000 bytes is very little, and even on a slow modem would take less than a second (particularly as with compression and it being all the same byte it'll be nothing)

Oscagne