We develop a Java web application which is run on Tomcat. It's been installed on many computers and it's working without problems. Recently, on a single remote installation, it exhibits very strange behavior: Sometimes content coming through HTTP to the browser is randomly shuffled - wrong data being served for a given URL. Most often it manifests as images being randomly exchanged on a web page. But it's not limited to images, it happened to me that instead of a HTML page the browser got one of the images instead.
I tried to debug the problem using FireBug + NetExport, and so far I gathered:
It appears randomly. Most of the time content is error-free, the problem occurs only from time to time.
The same application runs on many installations, but only this single installation produces the error.
It's not connected to a particular browser - we tried different browsers from different computers and the problem persists.
It occurs when viewed from the server itself (localhost) too, which rules out some broken transparent proxy on the way.
Both images and HTML pages are affected.
If wrong content is received, the data itself is consistent: Content-Length, Content-Type, ETags, etc. - everything matches the content. Just that it's wrong data for a given URL.
I'm truly puzzled, I've never seen such an error. I'd be grateful for any ideas how to investigate the problem further.
Related
I have a servlet-jsp web app. One of the requests in the login action is taking upto 120 sec to complete on Firefox and IE browsers. However this same request is completed normally in chrome (below 1 sec). On debugging the code I can conclude that my web app filter is returning the response quickly but the browser shows it took 120 sec to receive it. If you see the firefox developer tool below, it shows the waiting time to be 360ms and the receiving time as 120
s approx. This same behavior can be seen on IE also. Any clue what might be causing this?
EDIT 1: This issue is being observed only for requests that return a 302 response code.
EDIT 2: I tried using an intercepting tool to check the requests, for this I had to route the traffic through a proxy at 127.0.0.1 (localhost) . One observation is that while doing this the application is significantly faster. A possible explanation I observed for this is the proxy application returns the 302 requests with a status code of 200 to the browser. So now the question is why are 302 calls slow on the Firefox and IE browser?
Finally was able to resolve this issue from my app itself. In one of the places in the code the flush operation was being called upon the output stream of the response.
super.getOutputStream().flush();
This was only being done in cases when the request was not of type 302 which makes sense because 302s don't have any data in the response. Chrome is smart enough to see that and doesn't wait expecting any data. However, firefox and IE keep waiting for the data and thus the connection for that particular call is not closed. This causes the delay which can be seen in the image I attached in the question (browser tries to download content which never arrives).
I have now changed the code to do the flush operation for 302s calls also. This has resolved the entire problem.
Each browser has it own setting for handling connection. There are limits.
An answer-aggregation is already there:
how-to-solve-chromes-6-connection-limit
EDIT: Since the Question was edited, my answer don't match the topic anymore.
If a request of a web app act differently on different browsers, then the issue should be on the client side. (in the scope of single request-response interaction)
I have a Java web application that runs on a Tomcat server in a production environment. The application which is built with the Stripes framework works fine but almost every day exceptions are logged in the catalina.log files. Here is, for example, one of the log messages:
net.sourceforge.stripes.exception.ActionBeanNotFoundException: Could not locate an ActionBean that is bound to the URL [/admin/start/Welcome.action].
“/start/Welcome.action” is a valid URL but the URL “/admin/start/Welcome.action” is not present anywhere in my project files. I have no idea where it originates from.
Here are other invalid URLs that are also listed in the log files:
/wordpress/start/Welcome.action
/downloader/start/Welcome.action
/manager/start/Welcome.action
/admin/content/sitetree/start/Welcome.action
These URLs do not exist and have never existed in my application. Apart from them there is another group of ActionBeanNotFoundException messages about URLs that have once existed in the application but they do not any more.
Do you have an explanation of this? I asked this question to my hosting provider but they were unable to answer me. Any ideas would be appreciated!
There are two possibilities: Either some component in your web application generates such a URL - just in esoteric places that people rarely click on. If your application is available on the internet, those links in esoteric places might provide a place for the google bot (or any other bot for that matter) to try what's available in those locations, thus requesting the nonexistent URL. You don't need to go to bots for that matter, some browsers prefetch some URLs before you click.
Another option would be internet background chatter - various computers worldwide try to randomly identify vulnerable systems by just requesting well-known pages in order to find security holes in old software. The URLs that you mention (ending in .action) don't look like those though.
I am experiencing a weird problem in a GWT application. I have multiple RPC calls which work correctly, however if one of them takes longer than 30 seconds on the server side (for example a database or web service call took a long time), the server side code gets repeated (literally; the code get executed again).
I do not experience this in my develompent environment, however when I deploy the application (container is Jetty 6.1.24 on Ubuntu 12.04 LTS) and connect to it from a browser (regardless of the type), the problem starts to exist.
Since I do not think this a designed GWT behaviour (but I might be wrong ofcourse) I am basically looking for ways to debug this and find out the reason for it. Thanks in advance!
Some more information would be great to understand what is going on, but I would start the investigation by first narrowing down whether the erroneous GWT-RPC call is triggered on the client or server.
To see if the extra GWT-RPC request originates from the browser, in Google Chrome, go to View->Developer->Developer Tools.. Click on the Network Tab.
As you reproduce your steps, the Network Tab will show you every request sent to the server.
If you see the erroneous GWT-RPC request logged in this Network Tab View, then the request is fired off from the GWT-compiled Javascript in the application. With SuperDevMode, you can then set debug breakpoints in the browser and see what is triggering the request.
If the erroneous GWT-RPC is not shown in the Network Tab View, then the server-side method is somehow triggered by your server code/configuration. Set some debug breakpoints on your server code, and drill down the call stack to see what is calling the method.
Hope that helps to get started on the investigation.
I have a Java web app that deploys as a WAR to Tomcat 7.0.41 (myapp.war). I noticed that when I deploy the WAR to a Tomcat that lives in one part of our network, the web pages display perfectly fine. However, and this only happens in IE 11, if I take the exact same WAR and deploy it to the exact same version/Chef-configured-instance of a Tomcat server that lives in another part of our network, the page stylings look way different and completely wrong. Again, this is specific to IE11 and the location in the network that the app is served from. If I go to the app in IE 11 from a "good" location on the network, the frontend renders perfectly fine. Or if I view the app from a "bad" location on the network, but in a non-IE browser, again all is well.
I have a feeling that we might have some IT proxy (nginx, etc.) that is preventing Tomcat from serving certain CSS/JS files, and so the end result is a partially-complete frontend that looks all wonky in the browser. And somehow, this only crops up in IE 11.
I have (sort of) confirmed this by viewing the source of all my HTML, JS and CSS files and copying them to files in a local folder. I then open up one of the HTML files (locally) in a browser and the site displays perfectly.
The problem here is that my JS files use a bunch of open source JS libraries. And those libraries have dependencies on other libraries. So on and so forth, and the dependency graph is pretty huge. It's tough for me to tell which files are not being downloaded properly/completely.
Here's the kicker: if I add in html5shiv to my app then the problem goes away entirely, no matter which browser (IE or not) or what location in the network I choose. However adding html5shiv breaks other things in my app, and for reasons outside the context of this question, can't be used.
Anyone have any idea how I could troubleshoot/fix this? Why would this only be affecting IE 11 and not other browsers? Why is html5shiv solving this?!?
You need to start using Wireshark.
What it does is capture all network traffic and allow you to view it exactly as it was sent/received by your network card.
What I would do is capture the complete traffic that occurs between your computer and the server in the location where it is working, when you visit the webpage that has the problem. Then repeat that for the server that is not working.
You will then have the complete traffic and can compare them side by side. Even if it doesn't tell you the cause of the problem Wireshark will tell you where the difference is occurring in the packets that are sent by the two different servers.
You could also do it the other way round by running TCPDump (with command like tcpdump -i eth0 -w file.cap -s 0 to get the complete packets, rather than just the first X bytes) on the server, to capture the packets sent, and then viewing the capture in Wireshark.
"Does Wireshark offer such file-level abstractions or is it all nitty-gritty, byte-level output I need to read?"
Kind of both. Basically once you have the stream in front of you, you are able to see the individual requests starting by looking for GET entries in the packets.
Once you've identified where a file starts, you can right-click on that packet, choose follow TCP stream and it will give you a summarised view of that TCP stream:
If you need the detailed difference between the files, it will be there....but tbh it's probably going to be something obvious like a file being completely truncated or mangled, rather than just a byte or two being wrong in one of the files.
On WebSphere portal I am trying to use JasperReport print functionality.
JasperPrintManager.printReport(jasperPrint, true);
This way works fine for WAS and localhost.
But when I deploy the application on Remote server, the dialog of print is not appearing and no printing work is done.
Although I have used JavaPrint service to lookup all the printers and then select one for printing the task but it is not even working that way.
Your solution works on localhost because your client and server are the same machine. Thus calling a print command on the server side will make it look like it's printing from the client.
But you don't want it to print on server. You want the client's browser to have access to the report in a printable format. A common format is PDF.
As #AlexK mentions in the comments, there are already multiple other questions (with answers) on how to do this.
My suggestion for getting this done in a portlet is to have a button in your portlet view that will make a call to a serveResourceURL and download a PDF version of the report. The serveResource method was designed for situations like this where developers need to serve content other than HTML.