Is there a best practice for avoiding a browser freeze when loading an applet?
For my precise needs, the applet needs to be loaded when the web application is initialized, and is not a visual component (will be in a hidden div or hidden iframe).
As a reference, here is an old bug on SUN's side.
Essentially, no there is not. Read the evaluation section of the bug you linked to. The issue is one of startup time for the JVM. About the best you can do is to keep the applet small so that it will load quickly. However, the browser freeze is happening because the browser has to wait for the VM to start. You can't ever drop that time to 0, so a short freeze is unavoidable.
1.6.0u10 will help greatly with most browsers, but with the older vms there is no way to avoid the browser freeze.
Related
I'm using Selenium (in Java) to do programmatic browsing (Firefox) and, to speed up page loading, I'm going through a programmatic Java proxy running in the same application (Browsermob) to prevent the loading of external content (ads, etc) as I only need website's hosted content.
The application is browsing through hundreds of thousands of pages but unfortunately, after a few hours, speed is reducing significantly (from ~5s/page to ~30s/page).
Can it be related to browser cache size? Proxy cache? How to check?
Any pointer or hint would be more than welcome!
Many thanks,
Tom
Hi I would change your User Agent to something like Chrome to check wether or not Firefox is the problem or if its down to memory management in your app.
Are you closing down the Browser after a number of views? remember the browser will cache and start to take up a lot of memory. It may be better for you to use a text based browser (Lynx) in your app that removes a lot of overheads if your are simply going for text content.
Id kill the process every so often as memory leaks will cause the process to slow over time.
I have a JavaFX application, when the user closes the window, I want to destroy all of the JavaFX related resources and only have a tray icon, where the user can then reopen the application.
I have many background threads running, which should stay running when the GUI is closed. I have tried using Platform.exit() however it has no impact on the RAM usage of the program.
What is the best way to accomplish this? My goal is to reduce the impact on the system from my program as much as possible when the application is closed, but still running all of the background threads.
One option is to run the application as a separate process, launching the process when you want to create the application and exiting the process when the application is no longer needed (so completing a full application lifecycle). That way you will be absolutely sure that the application is not consuming any resources when it is not being used, because it won't be running.
How you would accomplish the launching and any communication between your tray service and the application would be up to you. You can research various mechanisms and, if you decide to go this route, ask some new follow up questions on accomplishing certain aspects of the task.
Some example routes you could look at are the ProcessBuilder, which is admittedly a pretty finicky and horrible API or the new Process API updates that will be available with Java 9. If wish to ensure at most a single instance of the application process is ever used, there are solutions for that. If you need to send a signal to the running application process, you could use something like RMI or run a basic HTTP REST server in your application and send messages into that.
As an aside, years ago there used to be some ongoing work on building multi-process JVMs, but there was never any wide uptake of the idea for Java. Though most modern browser clients, such as Chrome and Firefox, are multi-process architectures, the linked articles give some insight into this architecture, some of the potential implications of it and why it used for those applications.
Before going such a route, I would advise you to ensure that such an approach is truly necessary for your application (as pointed out by user npace in comments).
OK, this is driving me insane! It used to be infrequent and now its practically ever character I type that causes Eclipse goes into 'Not Responding' and CPU rockets towards 100% and stays there for a minute. Sometimes this is accompanied by node.exe taking half the CPU and a LOT of memory. I kill node.exe and sometimes it stays off but mostly it comes back.
I've looked up node.exe and can't figure out what it has to do with my application. I'm writing a webapp using Tomcat, Struts, Java, JSP, JQuery. I disabled every plugin from Preferences->startup/shutdown with no effect.
Help! I can't develop when every keypress takes a minute!
Take a look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=442049 or https://github.com/Nodeclipse/nodeclipse-1/issues/159
I overcomed by removing <nature>org.eclipse.wst.jsdt.core.jsNature</nature>
But you may have other JSDT related issue.
And you must know exactly what process is consuming CPU at what rate.
I would really suggest not using Eclipse for node. Try NotePad++ on Windows or Sublime or Atom or something...
I've written a Java app that allows users to script mouse/keyboard input (JMacro, link not important, only for the curious). I personally use the application to automate character actions in an online game overnight while I sleep. Unfortunately, I keep coming back to the computer in the morning to find it unresponsive. Upon further testing, I'm finding that my application causes the computer to become unresponsive after about 10 minutes of user idle time (even if the application itself it simulating user activity). I can't seem to pin-point the issue, so I'm hoping somebody else might have a suggestion of where to look or what might be causing the issue.
The relevant symptoms and characteristics:
Unresponsiveness occurs after user is idle for 10 minutes
User can still move the mouse pointer around the screen
Everything but the mouse appears frozen... mouse clicks have no effect and no applications update their displays, including the Windows 7 desktop
I left the task manager up along the with the app overnight so I could see the last task manager image before the screen freezes... the Java app is at normal CPU/Memory usage and total CPU usage is only ~1%
After moving the mouse (in other words, the user comes back from being idle), the screen image starts updating again within 30 minutes (this is very hit and miss... sometimes 10 minutes, sometimes no results after two hours)
User can CTRL-ALT-DEL to get to Windows 7's CTRL-ALT-DEL screen (after a 30 second pause). User is still able to move mouse pointer, but clicking any of the button options causes the screen to appear to freeze again
On some very rare occasions, the system never freezes, and I come back to it in the morning with full responsiveness
The Java app automatically stops input scripting in the middle of the night, so Windows 7 detects "real" idleness and turns the monitors into Standby mode... which they successfully come out of upon manually moving the mouse in the morning when I wake up, even though the desktop display still appears frozen
Given the symptoms and characteristics of the issue, it's as if the Java app is causing the desktop display of the logged in user to stop updating, including any running applications.
Programming concepts and Java packages used:
Multi-threading
Standard out and err are rerouted to a javax.swing.JTextArea
The application uses a Swing GUI
awt.Robot (very heavily used)
awt.PointerInfo
awt.MouseInfo
System Specs:
Windows 7 Professional
Java 1.6.0 u17
In conclusion, I should stress that I'm not looking for any specific solutions, as I'm not asking a very specific question. I'm just wondering if anybody has run into a similar problem when using the Java libraries that I'm using. I would also gladly appreciate any suggestions for things to try to attempt to further pinpoint what is causing my problem.
Thanks!
Ross
PS, I'll post an update/answer if I manage to stumble across anything else while I continue to debug this.
Update: my app involved multi-threaded processes each initializing their own Robot objects and creating input events asynchronously. I refactored the app to only contain one Robot singleton object, but the different processes still asynchronously invoke input commands. As far as I can tell, this did not change the behavior of my app. My next step might be to created a synchronized wrapper around the Robot singleton to see if that helps, but given the symptoms, I don't know why it would.
I've had problems using the Robot class before. I forget exactly what I've done, but it has caused the computer to lock up and I've been forced to reboot.
I'm not familiar with the vagaries of Robot, but Uncaught exceptions in GUI applications can produce very odd results as the event dispatch thread dies and restarts. You might get some ideas from How uncaught exceptions are handled.
This can happen if u activated any screen saver or some thing like that, then this robot actions will stop working
i got this problem in the following way
i am having some GUI based applications and i written some test code based on Robot class.
but if i activated screen saver in my system this test cases stopped working...
please check any such scenarios are there in your case
for Ross, I am pretty sure that you have a policy problem which mean that you don't have permission and getting block by win7. To get this permission you must create a policy and that is a big of a story. Check what info you can get from sun website.
For the others if your program stops working after some period of time it might be that you are not handling all of the exception in your program right. Try to get the line when it stops: you can do it by just sending a line of text to the system console, and rewrite it to get the performance you want.
For the rest check your code and check it good very good to see that you are not getting into a dead lock which might stuck your pc if it has something with it.
Also check to see the CPU usage and see if your program is overloading it if it does your CPU temperature control will restart or turn off your PC automatically.
If i didn't hit the problem, let me know; if you solved the case please let me know what you did.
We have two machines with almost exactly same behavior with Java applications.
One is with Windows 7 64 bit, where Eclipse 64bit and Java 6 (64bit) is causing exactly same freeze.
Other is with Windows 7 32 bit and Java application utilizing a lot of CPU and disk activity causing freeze.
Both machines are notebooks from Toshiba with modern CPU's (Core 2 Duo).
Also both machines have NOD32 anti virus installed.
Standard apps (Office, Skype, Firefox,...)
We seem to tracked down problem to NOD32. When we disable NOD32 it seems that beahaviour does not occure anymore.
I want to point out that I don't think it's NOD32 itself, but some combination of Windows 7, Java JDK and NOD32.
I ran into a similar issue on Mac OS X 10.6.7 but it was not freezing entire system but the entire java process where my application was running in, and interesting at random basis. Workaround for this was call:
Toolkit.getDefaultToolkit();
Before create any Robot, in example:
public static void main(String[] args) {
Toolkit.getDefaultToolkit();
//Blah blah
}
Same call is made in init method at Robot class so seems where the problems are coming from, this is stupid and does not make a lot sense to me but works perfectly now :)
Is this possible?
With the right architecture, for many kinds of applications - sure.
Just split the GUI and "core logic" into separate processes, and have the GUI able to detect and reattach to the running backend process when you run it after the crash.
For extra robustness, given that an X crash can often take down the whole system, move to a classic client/server architecture with the backend running over the network.
No. X11 is the foundation for the window manager and then the Java Swing application that runs in that window environment. So if X11 crashes there's not much you can do.
In addition to what wrt said, your backend system could also watch for HeadlessExceptions, and handle them appropriately.
It is generally not practical for an X11 desktop application to recover from a crashed X11 service, whether it is written in Java or another language.
But it may be possible to prevent the problem happening to a Java app the first place. I recall having to deal with this a long time (5+ years) ago. Sun had a workaround that involved setting a system property to tell the JVM to not use 2D graphics acceleration. I cannot recall the details, but you may be able to find an equivalent solution on the Sun website.