I have a problem.
Sometimes when I close my Java applet using the "Close button" in the upper right corner, the console freezes and becomes nonrespondable. The Java process does not shutdown and proceeds to use the maximum of a CPU.
It is only in one of ten times that this happends. It is also not dependant on browsers.
I have made sure that all my threads are properly shutdown along with my threadpool executors.
This is also only happening in applet mode. When I run this in Netbeans, I have never encountered this problem.
I am using Netbeans on Windows.
What could be the reason for the Java console to be hanging like that ?
And how can I determine what the causes of this hanging could be ?
Run your applet in debug more (see here how to do it in Eclipse).
Create a remote debug launch config (see link above).
Close the applet
When the bug happens, start the remote debug launch and pause the whole VM. Now you can inspect the threads to see what happens.
Related
Dear all please help me
when I run the project it stills running all over the time
when I repeat running multi-times I found processor processes more then 10 project s !!!!!
NetBeans allows multiple executions of the same project at the same time. What's probably happening is that app is not shutting down when you close its main window.
The reason: closing a JFrame window doesn't necessarily shut down your application. Unless you say otherwise, the default behavior is to simply hide the window and keep the application running.
If you check the DefaultCloseOperation property of your app's JFrame, you'll probably find that it's currently set to HIDE_ON_CLOSE. Change that to EXIT_ON_CLOSE and your application will shut down when the window is closed.
Note that you can still start multiple copies of your application at the same time, if you so desire. But with the application actually shutting down when you close its window, you're now less likely to find yourself accidentally knee-deep in multiple running copies that you thought you had previously killed.
Read all about window-closing options here.
I'm developing a Java desktop application for Windows and I'm trying to implement the Windows Restart Manager. I'm successfully receiving the Windows messages for exiting the application and when I send them manually, it just works and the application shut downs.
When I do it as part of the uninstall process, the shutdown procedure in my application runs and I can even see it calls System.exit(0) but even after that, there's a process that doesn't stop. My Java application is packaged into an executable file using launch4j in case that's relevant.
The way I know System.exit(0) is being called is because I'm dumping debugging information to a file and I print out that System.exit(0) is about to be call and I can see that whether the application succeeds or fails on properly shutting down.
Using the Process Explorer I can see the javaw.exe sub-process and when the exit procedure happens, that goes away, but the parent process remains. While the is running, it looks like this:
and after the failed exit, it looks like this:
If I have a remote debugger connected to the process, at this point, the debugger gets disconnected.
What could be causing this?
I'm close to being convinced this is a bug in launch4j, so, I reported it here: https://sourceforge.net/p/launch4j/bugs/185/
When run the project second time, can the previous JFrame closed before open the new one ?
So I no need to close the JFrame when trying to run the project second time.
Is it possible to open only one JFrame?
Eclipse has the possibility of terminating the launched program before starting the new one:
It is called Terminate and Relaunch (see the Documentation).
You can bind this to any shortcut you like (Window -> Preferences -> General -> Keys).
Apparently, eclipse offers some special options to get what you want.
For other people who might be using a different editor: it's possible, but you'd need some kind of communication between the processes.
What you can do is this, make a server application that runs independently and have it open before you start your regular application. When you run your regular application, connect to the server. This server now messages the other application that was running to close down.
If running a server application is too much trouble, you can run both the server and the client in the same application. When you start the application, check if the designated port is busy, if not, create a server. If it is busy, connect to the server and tell it to shut down. After that, open the server socket in the new application.
Select the Terminate and Relaunch command [ Terminate and Relaunch ] to first terminate the selected debug target and secondly, relaunch it.
Once a launch is terminated it can be automatically removed from the Debug View. To change this setting use the Opens the Launching preference page Run/Debug > Launching preference page.
you may find relaunch-plugin for eclipse useful for your case.
I don't know about eclipse but i usually run two or more JFrame applications in (IntelliJ idea) belonging to different classes at a time. The previous one will not be closed. One more thing i would like to suggest you to use IntelliJ Idea from Jetbrains company as the UI,shortcuts and all other stuff are same as in Android Developer kit(studio) which is also sponsored and developed by Jetbrains!..
You can check the JFrame applications running simultaneously in this image.
Hope this answer is somewhat informative.......
!>...
My project is basically a Communication client like lync which is developed in JAVA for front end (GUI) and uses platform specific native (C or C++) code for running services.
Now, on Linux, (Ubuntu 12.04), once the JAR application is invoked, it loads all the native code shared libraries and the UI thread starts executing. Any action done in the UI will throw an event to the native code which is in C. So currently i need to debug a crash in a C/C++ user library which is triggered when i do something in a UI drop down.
I am using GDB, to attach to the PID of the process , (sudo gdb -p ), all the symbols are loaded and i am able to set a breakpoint to a function say A() in the library.After continue command in GDB, i select the instance from UI Dropdown and breakpoint is hit at Function A(). At this moment, my ubuntu machine hangs and no keyboard interrupts are working. I am only able to move my mouse pointer but cannot click on anything.
However, to verify that kernel is not down, i can ping the machine and even SSH is possible. Once the same GDB is invoked by SSH the above problem is not encountered. May anyone please help me out here as to why UI or X11 process hangs during the above scenario.
PS: Yes there are lot of threads running, it might be a thread deadlock situation but it does not happen when GDB is invoked by SSH terminal.
Thanks and Regards,
Indra
why UI or X11 process hangs during the above scenario
As Mark Plotnick correctly pointed out, the X11 process does not hang. Rather, it grabs the keybard (all keyboard events are dispatched to it), and can not release that grab (it is stopped by GDB before it reaches the release point).
There are two common solutions:
ask the application to not do the keyboard grab (as Mark said), or
debug the application from a separate machine (this can even be done on single physical machine: just run the application inside a VM).
P.S. Why do application menues grab keyboard? Because hitting Esc usually dismisses the menu, and they want to see that Esc regardless of whether the application has input focus or not).
I have an applet packaged with a third part dll (from JTwain). My applet scans documents from the TWAIN compatible default printer. The applet fails on a paper jam and won't recover. The user navigates away from the page and the applet is destroyed. When returning to the page it fails again. Closing the browser (which kills java.exe process on the pc), and then returning to the page clears the problem and everything works.
I want to restart everything without requiring users to close down the browser. I've added a GUID query string to the URL's from which the applets resources are loaded - so I know nothing is being cached. I've checked in the windows task manager and there is no process created by the dll, it's all happening within the main java.exe process. I tried wrapping the scanning process in a thread so I could interrupt it in the stop or destroy methods (just in case the applets thread weren't stopped when the applet was destroyed), but that didn't work.
Any suggest would be greatly appreciated. Ideally I'd like some way to restart java when the applet unloads (but I doubt that's possible).
UPDATE
I've spent a couple of days trying to identify what causes the applet to fail. I still don't know :(
When the paper jam occurs something (not my code), is producing a couple of popups. The first alerts the user of the jam, and can be closed by clicking the OK button. The second says 'reading from device' and hangs. It cannot be close with the red, close window, icon in the top corner - I kill it from the task manager and windows asks to send a report regarding the 'non-responsive program'. I assume these popups are produced by the dll. And given that the second hangs, my assumption is that a thread started by the dll has hung while retaining a lock on some component of the TWAIN application. I get
com.asprise.util.jtwain.JTwainException: Failed to open the specified data source:
Source: TW-Brother MFC-9970CDW LAN Thrown
..when I try to access the scanner.
I'm at a bit of a loss as to how I can get more information. I'm testing my applet on a windows virtual pc (so as to use ie7), and don't have a method for step debugging in this environment. (And it's crashing on third party code for which I have no source anyway)
I see only two practical options here:
Use an API that handles paper jam without problems. Of course, that is easy to say (get robust API), harder to find.
Launch the app. free floating using Java Web Start. If it freezes up, the user can kill it and click the link for another instance in a new JVM. Or the applet might also call BasicService.showDocument(URLof.jnlp) if it can detect a problem with the DLL and is not itself frozen.
Of course, you should also report the bug to the ..Asprise(?) developers. The optimal solution would be to have the problem fixed at its source. Anything we do here is a 'workaround'.