I have a JSP form, that (when the user clicks the "submit" button) instantiates a Java class, and calls a method on it. This method then submits a request (in a proprietary format) to a server running on an entirely different box. That back-end server then either sends the submitting user an email, and returns "SUCCESS" to the Java method, or it returns an error message.
Once the Java method returns from calling the program on the other box, it passes the result to the JSP, which either tells the user to expect an email, or displays the error message it got.
The problem is that this takes time to happen. And as the back-end server has evolved, and become more complex (it now has to call a web service running on a cloud server), that response time has gotten longer.
And now we have users who, because there's no immediate feedback, are either re-clicking the submit button, or refreshing.
Is there a way I can give the user some kind of immediate feedback, as soon as the JSP begins to process the "submit," that will be sent before the whole chain of instantiation, method call, remote system call, and so forth begins?
I found something on my own that will be good enough: I can do an "out.println()" followed by an "out.flush," and that will give immediate feedback. A quick-and-dirty test proves it out. And the fact that I wasn't already aware of it shows just how little I know about JSP (although I will note that it never came up in the first JSP tutorial I found, and it wasn't until I looked at other tutorials that I was even aware of its existence).
But I'd welcome a better solution.
Just as I always welcome constructive criticism.
Related
we implemented a paymentmethod with saved creditcards and 3dsecure (SAP commerce/hybris), but it's not always working. Sometimes a nullpointer for the orderData is thrown, after returning from the paymentservice. The reason for this seems to be, that the user sometimes is anonynoums after the return, so the orderData isn't visible.(the orderData exists by the way)
But I have no idea why this happens. And like I said it only happens occasionally on prod, but when I debbuged local it happend most of the time. And at the paymenservice the payment is authorized.
But it's difficult to debug, because there aren't any testcards to test with 3dscure, so I have to use a real one everytime.
To be honest, I am not sure if I am allowed to show the code here, so please forgive me, for not showing it now (I didn't write it).
Are there any "common" mistakes/suggestions/best-practices or whatever? Or maybe just an idea?
Oh, and we don't face this problem with other returns like paypal.
It's a bit tricky, since I don't know the code, but here are some advices:
Maybe the Session Cookie in the browser is destroyed somehow? You can check with the Browsers developer tools if the cookie is contained in all requests (Network Tab -> Click on the Request -> Request Header). This can sometimes happen if you switch between http/https or multiple subdomains.
Bad timing with an automatic logout of the user?
Are you using multiple cluster nodes? Maybe the session is not yet synchronised between the nodes?
Particularly, what are all the dots and numbers at the end for.
Here is an example:
https://www.google.com/search?site=&tbm=isch&source=hp&biw=1366&bih=673&q=kale&oq=kale&gs_l=img.3..0l10.403.1120.0.1352.4.4.0.0.0.0.407.543.0j1j4-1.2.0....0...1ac.1.32.img..2.2.542.vC-f2Kfx-2E
It is a GET variables value, but why such a strange un-human readable syntax?
I assume they are using PHP or Java on the back-end.
What you are seeing is internal computer data, not exactly intended for normal human consumption, but there for a good reason. Also perhaps you are thinking, why would anyone want these ugly internal details displayed on the average user's screen?
When HTTP was invented the thought was that GET requests should be stateful, in other words, if I copy a URI from my browser and email it to you, and you browse to it, then you should see exactly what I saw. To make this work the GET data needed to be in the URI and not hidden from view. Thus the dirty details you are seeing. Back in the day they were thinking of simple GET queries, for example: http://www.somedomain.com/Search?Find=FooBar
However, as software has evolved more data needs to be passed with GET requests and unfortunately it is all visible in the URI. (Note that this also becomes a minor security hole because the average user can see some of the internals of web page production and easily tamper with it.)
What is needed is a hidden data passing method for GET type queries to clean up URIs when it is not necessary for these details to be present. A proposal for such an improvement to HTTP is in the process of being considered. It would involve adding a new method to HTTP similar to GET but with hidden data passing like POST.
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 .
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
difference between jsp forward and redirect
Does anyone knows the differences between forwarding and redirection in Http servlets and the impact of these differences on browser refreshes?
forwarding is done without letting client know that, It is used to do internal communication at server, while in redirecting we are asking client go back and ask it over here.
Real life example
Forwarding
You went to postoffice there are number of boxes and person sitting there, now one of them accepts your request and it internally forwards it to other responsible person to fulfil your request and at the end of the process you will get the result
Redirecting
now the same person gives you a token which says goto window no5 and ask that person .
Also See
difference-between-jsp-forward-and-redirect
Read this wikipedia article, which explains it very clearly.
A forward just transfers the responsibility of a single request handling to a new server-dide component (example: servlet --> JSP). A redirect asks the browser to send a new request when a first one has been partially handled (example :create product --> redirect to list of products).
The post-redirect-get pattern, which is explained in the wikipedia article, explains when and why a redirect is preferrable.
fowarding happens on the server side. the server fowards a request to some other page and let that page handle it.
redirection plays between server and client. the server return some HTTP code (dont have in mind now) to the client which tells him the make a new GET request for the page redirected to, this happens without any user interaction.
Forward is transparent to the browser.
Redirect is not. It involves the browser loading a second URL. So I'd assume this is a bit slower.
See here for more info
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.