I am calling a thread in JSP page and that thread keeps on running. I want this thread to terminate when I close the JSP page. Wow would that be possible ?
my code put it in body tag JSP:
<%
Thread Ping=new PingThread();
Ping.Start();
%>
Thanks in Advance
You mean close it when the user closes the window? There is no event fired for that, so you can't do it. You could do that via JavaScript by making an Ajax call when the user closes the window, but it's probably not going to work anyway.
The doubt that comes to mind is: why would you do such an horrible thing as starting a thead in a JSP page? By spamming the F5 button someone could obtain the easiest DOS attack of the history! Rethink your application to avoid such a solution (launching threads blindly on request, not just the fact that you do it from a JSP).
If you start a thread from a JSP, it is to impossible to guarantee that the thread will be stopped when the user exits the page.
No notification is sent from the client to server when the user closes or moves away from a plain HTML page. None whatsoever.
You could include some javascript in a web page to perform an AJAX call to your server when the user closes the window or moves to a different page. However, there are scenarios where call won't get made; e.g.
the user's machine dies,
the user's browser crashes,
the user has javascript turned off,
the user sets a breakpoint in your code,
etcetera.
And even if the call is made, there's no guarantee that it won't get lost due to some transient networking problem.
The end result will be that your server has an orphaned thread that will keeping doing whatever it is doing (in this case, pounding some other machine with ICMP packets) until you kill your web container.
That's a really, really bad idea.
You can use the Javascript beforeunload or unload events to determine that the window is being closed, though which one you use and how depends on precisely what it is you want to do.
As Anthony Grist's answer says (sort of), you can embed javascript in your web page to be executed when the browser detects that the current browser window is being closed. Refer to this page for more details about DOM Events and their handling.
Notes:
This stuff works whether or not the page is a JSP. (For instance ... it would work if the page was plain HTML ... provided that there was something on the server end to deal with the notification.)
This event handling is performed in the users web browser.
The server side doesn't get told about the window closing, unless the event handlers send an (AJAX) request to the server to tell it.
As I said in an answer to a previous question, there event handling can be disabled on the client side by the user.
As I said in an answer to a previous question, there is no guarantee that the AJAX request will actually make it back to the server.
All of this adds up to the fact that any server side handling of the window close event is unreliable. And there's no solution to that. Not in theory, and not in practice.
you could enclose the above in another loop which is set to true by the jsp page throuh ajax call on a time to time basis. if the jsp page is not setting the value to true then you can safely assume that the browser is closed. But you would need an identifier for your thread like say session id or ip of the user.
Related
I'm currently working on an Android App which calls HTTPS Requests (like Login, etc.) to a Rest API. My first approach was to use AsyncTask to do this work not on the Main Thread. Unfortunately, I need to know if the Login was successful or not in order to proceed with the code, because if you are not logged in you have only limited access to other parts of the app.
I've tried it with AsyncTask because I used it in a previous project, but I noticed the problem with the return value a little bit to late and now I don't know what technology I should use in order to:
Don't block the main UI
Wait for a response
Evaluate the response with a boolean or something similar
I would appreciate if someone could help me with choosing the best way of accomplishing my problem
Use Retrofit for API calls.
But, it will be async as well. That's something you can't avoid.
If you have to wait for call finishes, and process to the app/dashboard, there is no other way.
Practice is to show loader over the screen, send request in async task, wait for response, hide loader, process to the app.
Not sure about your implementation, but other approach could be:
set as user is not logged in
process to the app handle user as he isn't logged in yet
when login request is successful, set some global variable that he's logged in
I submitted a request in my web application which may take long time to process the request and get response. Is there any way user can cancel the request in the middle by clicking a button in the web application.
Aborting the ajax request will not stop the request in the server side.
Is there any way to achieve this?
Why would a user want to cancel a request?
If it's long running, and they don't want to wait, a better idea might be to make it an asynchronous process. Return a receipt token to the user immediately and let them know they can come back later with their receipt to pick up the result. Provide a second method that takes in the token and returns the response.
Update:
You need to research to see if your database server has an API to allow you to cancel a process. That's the key thing here. If it doesn't you are out of luck. I'm not aware of any such thing in the JDBC API, so even if it does you'll have to figure out a way to get that command to the database.
I'm working on big liferay project and I have the following problem :
everytime when something is loading, processing etc. I should change cursor to waiting gif. It's easy when using Ajax, but in many cases here I don't use it. So I thought maybe if I could catch any action phase I'd somehow set cursor to wait at the beginning of action method and then turn back to regular 'auto' at the end.
Is that possible ? I don't like this 'solution' but I can't think of any better. Currently I have div with loading image in my jsp which is then removed by jquery document.ready() - not satisfied at all, because all the proccessing have been performed earlier in action phase.
I'd appreciate any suggestions.
Well, if you are not using Ajax, it might be difficult to achieve what you are looking for.
You could start showing the throbber ("loading image") once the link on the first page is clicked, keep it on the next page and remove it on document.ready().
But you'll still have a few ms or seconds without throbber, during page load.
If the processing time is really long, you could do the following :
The idea is to use a thread for the processing. A reference to the thread is stored in server's session. When the link is clicked :
Display a page with the loading image and start the processing in the thread
Poll the server every X second to check if the thread (in session !) is done
When the thread is done, display the result.
I have a long-lasting http request (a lot of computation in the back-end).
Currently it's all synchronous, while the server computer, the browser doesn't see the output/result. After a while, the connection is dropped and an timeout error is displayed in the browser.
I'd like to return some info to the browser right away, and make it wait for the result. How to achieve this?
Please note, that the Java back-end is synchronous. So a solution would require some hack in the servlet/front end possibly requiring javascript requests.. ?
You probably want to use the COMET pattern. It's like the AJAX pattern, only featuring long-held HTTP requests to simulate a feed. See here for a detailed explanation.
Basically, you fire off a request, the server holds it, then replies when it has something of interest. At the point of receiving the reply, you immediately fire off another long-held request.
This time-sequence makes it feel like a feed.
In your case, it could just return "yeah, I'm working on it" immediately and then reply with "still processing 10% done dude" and so on until you get back "done".
Things like node.js are really good at implementing this kind of functionality.
Although, as you're using a synchronous Java back end, you may need some kind of indication somewhere that progress is being made. Possibly a database.
Timeout won't occure as long as you write something to output stream (it can even be spaces, don't forget to call flush()).
Such long-lasting request makes sence when you, for example, print a large report, which is shown to the user subsequently as it is generated.
In all other cases, return the waiting page to the user and use periodical AJAX requests to ask if the processing has finished. When nothing changes and the browser is showing loading, it is not a good user experience.
The best solution would be to use AJAX requests. Once an ajax request times out you can send it again by using JavaScript(you can show some button). This is probably the best practice to handle timeouts.
I've been playing with Java Servlets and Ajax a bit, and I've got
a situation on which I would really appreciate advice.
Let's say I have HTML page with a start and stop buttons, and as a result of clicking start button,
overridden doGet (or doPost) method on a servlet is invoked which computes something that takes a long time to complete.
(e.g. a giant loop, or even Infinite loop, doesn't matter, I'm interested in concepts here).
So, I'm asking you:
1.What would be my options to kill / shut down / halt / exit
doGet method whan I hit stop button on a web page?
Do I use threading here, or there is simpler way?
I take it that using System exit is not a very good idea, right? ;)
2.So, let's say I implement code for stopping doGet method.
What would happen If I hit start on one browser(e.g.IE), and while this long
computation takes place open new tab or other browser(e.g.Firefox) and open same url
and hit stop? Would that stop my original computation? Is there any easy way to avoid this?
I know that questions are a bit off, as I'm just starting with server-side of things. :)
Any suggestions would be greatly appreciated!
your stop handler can set a flag in the session context, which the long-running thread will occasionally check and exit if necessary.
you can avoid the multiple browser issue, by generating a unique task id each time the page is loaded. then you can only start or stop a specific task. this id can be a key in the session.
I think you need some kind of new process started after you submit request and this process should answer responses during runtime (showing progress for example via AJAX). Also it should check if there is new request with stop command. Page should be AJAX one with progress/result/stop button.