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.
Related
I have a process that splits into many different branches. The business requirement is that at any step, the process has to sent back to the process originator for correction and re-approval.
I know it would be possible to to use gateway logic at the end of each step and have the process return to the beginning that way; however, this would add many lines and branches to the process so that it would be incredibly difficult to read. I was thinking that an alternate way to accomplish this would be to simply abort the process and restart based on the information in the existing process - this seems more maintainable.
Both of these would not be too hard to implement, but I am wondering if there is an easier way to achieve this goal. I have not worked with signals much, but is there a way to leverage that to return to a previous step in the process?
Start of Editted Solution
Based on #Kris Verlaenen suggestion, it created the example process below.
I started by putting all of the steps that can be might be skipped into an Embedded SubProcess. The Return, Rejection, and Cancel signals were added from the Boundary Events tab of the palette. While the process waits for the Supervisor or Manager approval to complete, you can send a either of the signals to either go back to the first step or jump to the end of the process.
Using a event sub-process could allow you to trigger some part of your process every time the event occurs (could be signal, error, etc.)
Using an embedded sub-process with boundary event might help, as that way you would only have to link back grom that boundary event to the start, and whenever a signal / error occurs inside the sub-process, the boundary event could catch this. You could even make it interrupting, meaning it would cancel anything inside the sub-process as well, basically resetting what you were doing.
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.
Suppose, this is in any jsp with servlet project.
I clicked a button to calculate something, and the process will be done in a few steps or by using some synchronized threads that need nearly 5 hours.
If I close the browser window after a click, what will happen?
Will the calculation process stop or continue?
If its the latter (continue), and I log in to my account after 2 hours, what will I see?
I want to see the calculation progress real time.
What should i do?
This kind of processing requires planning. There are many edge cases. What if the process is already running? What to do if the server terminates in the middle of processing? Can you restart? Can the processing be interrupted? Can every user start this processing, or just authorized ones?
Ok, now to an answer. You want to run the processing in a separate, background thread. See the Executor classes. Then you have to store the progress of that processing somewhere (think db here) and create another page to show that progress. You may also have to remember the user that started the processing, so that you know which of the progress information to show to the user requesting the progress.
So, simple! :)
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.