Is there a quite easy way to implement progress bars in JSP. Basically I have a JSP page that goes to a servlet that calls up a method, now this process is going to run for a long time and I want to indicate the status of the progress just like the progress bar that shows up in the eclipse taskbar when we execute any java program.
I have found a nice tutorial here http://onjava.com/pub/a/onjava/2003/06/11/jsp_progressbars.html but it seems little outdated.
Are there any new and easy ways to implement this?
Determining the progress of a particular task is a surprisingly complicated thing once you get into the details. How do you determine for example that you are 50% done? And what happens if the last 10% of your task takes 1/2 the total time?
Usually for a web app, if you do want progress bars, then going the AJAX route is best, as some of the posters mentioned above.
I find, however, that on the web, it is suitable to indicate to the user the something is happening. Just have a spinner of some sort made visible when the page is submitted, and then hidden again when it is rendered (see here). This is very easy to do, causes no additional performance hit, and is indicative of some sort of progress
There is a lot of solutions for example jQuery.
You can use Jquery with Ajax to update progress bar:
http://jqueryui.com/demos/progressbar/
In my opinion, when you call your jsp, it should return to the user immediately but also indicate that some complex task is being dealt with in the background (with a loading spinner, for example). If you want to know the task's progress, you should use either Ajax polling, or Comet push in order to retrieve it from your server. For just getting and displaying progress, I think Ajax is sufficient and Comet might be a bit of an overkill. Here is more on the Ajax approach:
http://en.wikipedia.org/wiki/Ajax_(programming)
More on your question, a servlet(and also a jsp) work according to the HTTP protocol, which is based on the request->response model. In today's world, there are rarely sites where you go to a jsp to do a complex task and then you have to sit around doing nothing while your request is complete. You might want to give your user the freedom to still interact with your web-application/website while his request is being dealt with in the background.
Related
Ok .. I think this question is dumb but its something I need so asking.
I have a servlet that checks health status of about 20-50 servers depending on situations.
I am trying to reduce the time to as low as possible but it still takes me 15-20 seconds to respond.
I am printing stuff on console for my satisfaction that the servlet isnt stuch but a user cant see that.
Is there any way I could print data on the requesting or a new page so that user knows that server isnt stuck - I dont wanna pass the request as there is still some processing to do.
I just want to print like I do in console. I checked System.setOut(PrintStream) but this also caries the data only after I pass request dispatcher - not good for me.
I am sorry if its a dumb question. I couldn't find a solution for my problem. Any help will be appreciated. Thanks in advance.
UPDATE: I am currently displaying a picture that says loading. But even if the server crashes the picture is still there. In my case its not true indication of servers state.
I think what you are looking for is supported by WebSockets, https://www.google.com/search?q=websockets.
You'll have to update your javascript, assuming your browser supports it, and then update your servlet code, and container to support. Jetty supports it, I'm not sure about the other containers.
Or alternatively, you could save your progress to a table or something and poll that data.
With the first request you could show a page with some kind of "please wait" indicator and do a second request that actually fetches the data (eg. via JavaScript).
Show a loading bar using javascript . This would tell the user that something is happening in the background .
I'm building a page that has a search box that will populate a grid on the same page. There is also a button the user can select to bring up a "window" (JQuery UI "pop-up" in the same page) that lets the user configure said grid.
These are two separate forms but I don't want what was submitted as part of one to undo the other (so when the user submits to change the grid layout the search needs to re-run as well.
I'd rather not store things in session for this since that brings with it its own issues (search results may be large, shouldn't be saved when the page is re-entered later, etc.).
I've considered doing "one large form" (i.e. surrounding all the inputs) for the entire page that is backed by a form backing bean. I would then use which button is clicked to determine the action to take. There will eventually be other buttons on the page as well to add more functionality. This would be similar to how .NET (non-MVC) handles things.
I'm interested in how others may have solved similar challenges. Are there potential issues with my approach that I'm not seeing? Better ways that work with the framework?
What do you mean with:
but I don't want what was submitted as part of one to undo the other
. Are you referring to posting the form and loading the whole page, which in turn will "reset" the other form?
If that is the case I would still keep one page with two forms and make the posts using Ajax (as you may know jQuery makes this a breeze). Upon receiving a response for either call you will need to update the other form accordingly.
Note that you may still have your forms in two separate views if it helps keeping the code clean and then pull their html with Ajax calls into another view. But my point is that at the end I would still keep both in one page since it sounds like they depend on each other so updating one when the other changes may be easier this way,
Let me know if I misunderstood your question.
I have a software design question on what's the best way to handle a client javascript program that relies in multiple (but mostly consecutive, not simultaneous), short-lived AJAX calls to the server as a response to user interaction [in my particular case, it will be a facebook-GAE/J app, but I believe the question is relevant to any client(browser)/server design].
First, I asked this question: What is the life span of an ajax call? . Based on BalusC answer (I encourage it to read it there), the short answer is "that's up to the browser". So, right now I do not have really control of what's happening after the server sent the response.
If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?
Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?
Is it possible to manually set the limit per domain?
And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.
Thank you in advance
The usage paradigm for XHR is that you don't have to worry about what happens to the object -- the browser's engine takes care of that behind the scenes for you. So I don't see any point in attempting to "improve" things manually. Browser developers are certainly aware that 99.9999% of JS programmers do not do that, so they have not only taken it into account but probably optimized for that scenario as well.
You should not worry about it unless and until you have a concrete problem in your hands.
As for limiting the number of AJAX calls per domain (either concurrent outstanding calls, or total calls made, or any other metric you might be interested in), the solution would be the venerable CS classic: add another layer of abstraction.
In this case, the extra layer of abstraction would be a function through which all AJAX calls would be routed through; you can then implement logic that tracks the progress of each call (per domain if you want it to) and rejects or postpones incoming calls based on that state. It won't be easy to get it correctly, but it's certainly doable.
However, I suggest also not worrying about this unless and until you have a concrete problem in your hands. :)
Update:
Browsers do enforce their own limits on concurrent AJAX calls; there's a very good question about that here: How many concurrent AJAX (XmlHttpRequest) requests are allowed in popular browsers?
Also, as T. J. Crowder mentions in the comments: make sure you are not keeping references to XHR objects when you are done with them, so that they can be garbage collected -- otherwise, you are creating a resource leak yourself.
Second update:
There is a good blog post about reusing XHR here -- it's actually the start of a chain of relevant posts. On the down side, it's dated and it doesn't come to any practical conclusion. But it covers the mechanics of reusing XHR well.
If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?
It only aborts the running request. It does not close the connection.
Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?
Not possible. It's the browser's responsibility.
Is it possible to manually set the limit per domain?
Not possible from the server side on. This is a browser specific setting. Best what you could to is to ask in some page dialog the enduser to change the setting if not done yet. But this makes after all no sense, certainly not if the enduser does totally not understand the rationale behind this.
And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.
Yes, you should certainly worry about browser specific bugs. You want your application to work without issues, do you? Why wouldn't you just use an existing ajax library like jQuery? It has already handled all nasty bugs and details under the covers for you (which is many more than only MSIE memory leaking). Just call $.ajax(), $.get(), $.post() or $.getJSON() and that's it. I wouldn't attempt to reinvent the XHR handling wheel when you're fairly new to the materials. You can find some jQuery-Servlet communication examples in this answer.
I'm performing a validation task that takes a while and am spinning the validation process into a separate thread. I've got the progress bar side of things working, with PortableRenderer and a ViewScope allowing it to update the progress bar component.
However, I'm trying to redirect the user once the page either finishes or a error in validation occurs, without the need of user interaction.
I'm using AND new to icefaces2.0(beta 1) and JSF 2.0, so the answer might be right in front of me. Sorry if this is a pretty simple question.
Have ajax to execute this job rather than spawning a thread yourself.
Update as per the comments: well, that was a bit curt. But spawning a thread yourself inside a servletcontainer is recipe for major trouble if you don't know what you're doing. The functional requirement makes now a bit more sense. Your best bet is using IceFaces' push or poll component which in turn causes JavaScript in the client side to do a window.location on the desired URL.
I eventually fell back to my own way of doing it.
I'm putting the JSF bean into a session attribute with a portable renderer injected as a property. The session attribute is used since Spring cannot get the "View" scope. If there is a way for Spring to do so, that saves a lot of potential pitfalls, but alas I do not know how.
Once the page loads, a jquery AJAX call is made to a Spring Controller, which gets the JSF bean out of the session, removing it in the process, and proceeds to "validate it". As it proceeds, it sticks the current completion status into a session attribute and calls the bean function that invokes the portable renderer, which in turn updates the progress meter.
Also part of the page load function, is a separate function that calls another Spring Controller, which returns the completed status object, which may/may not have error messages.
I plan to remove the second controller by just checking values already on the page that get rendered by the portable renderer and publishing all those errors into the bean, which can then be rendered easily and dependably.
This way, as BalusC said, removes the creation of threads not directly spawned by the container and allows me to redirect automatically via window.location on successful completion.
If there is a better way to do this, which I imagine there is, please do add an answer. My knowledge with Icefaces and JSF is severely lacking currently and I'd thank anyone with the best way to do this.
Good evening,
I am in the process of writing a Java Servlet (Struts 2, Tomcat, JSP etc) which is capable of doing some fairly complex simulations. These can take up to 2 minutes to complete on the and will return a graph of the results. It is trivial to calculate the percentage of the simulation completed because the process works by repeating the same calculations 1000s of times.
I would be interested to know if anyone has ever tried to use client side technology to provide any estimate of the percentage complete. I.e query the servlet processing to get the number of cycles completed at various point throughout the simulation. This could then be displayed as a bar in the client browser.
Any thoughts, advice, resources would be much appreciated.
Thanks,
Alex
In your database, have a table to maintain a list of simulations along with their server-calculated progress.
In your web-application, use AJAX to query the server every few seconds (1-20 depending on load is what I'd go with) and update a graphical progress bar. Most javascript libraries have simple timer-based AJAX functions to do exactly this sort of thing.
There's a few details to figure out, such as whether or not completed simulations remain in the DB (could be useful logging info), but overall, this should be fairly simple.
You could encapsulate your response in a mime/multipart message and sends your updates until you have a full response done.
Bugzilla uses this in their search to show "Searching ..."-screen until the searchresult is done.
If you want to use plain Struts2, you should take a look at the ExecuteAndWait Interceptor.
It works by the old refresh-with-timeout method. Sure, it has lower coolness factor than some AJAX thing, but it's simple and works (I've used it).
Struts2 takes care (by using this interceptor) of executing the action method (which would typically take a long time) in a separate thread, and it returns a special result wait until the work is completed. You just have to code a jsp that shows some "waiting..." message for this result, and make it refresh to the same action, repeatedly, with (say) two or three seconds of timeout. The jsp has access to the action properties, of course, hence you can code some getProgress() method to show a progress message or bar.
AJAX is the way to go here.