We have bunch of jar files that are Java applications and run just fine. There are a few however that do nothing although it is expected to run :) with a GUI.
Is this a common issue with jar files that some have difficulties to run?
The OS is Windows 7 and the example not working jar is whitebox a free GIS application, BTW.
We reiterate that we have many jar applications that run like a charm in the above system. This means that it should not be a problem with Java installation (latest update 7u40 exists in the system).
We checked almost all jar failure related topics but no one discussing the issue above which is happening for some applications.
We also mention, we uninstalled and reinstalled java many times but with no success. The application whitebox does nothing. In one try, it did run and when we closed it. And we are since then trying to run it again but nothing is happening! Even nothing appears in the running Processes!
We examined command line and double click. No success. The file type association is correct. Furthermore as we said others are working just fine.
The problem reported was due to inadequate RAM. Whitebox requires 2GB RAM to run smoothly. While this is huge we could run it on an old laptop with only 1GB RAM. The solution was to increase the size of paging file (virtual memory) into the range 1024MB and 2048MB. We also moved its location from C drive into other drives. We the settings mentioned it runs without any problem. We have tried it many times and happy to report for this case the problem is now completely solved.
Conclusion:
For some Java applications if something happend as described in the question it may be due to memory requirement. In this case increasing virtual memory could solve the problem without a need to buy additional RAM.
Related
I have a computer with 32 GB of RAM.
I am testing a software and I can see that it starts to work slowly when task manager says that it is using more than 6000 and something MB.
In the log file, I can see:
name of the application, running on 8 cpu cores and 6367MB memory.
I have followed this tutorial and setted 24576MB but it still doing the same.
I just have the binaries (.exe files), not the code.
Any solution? Thank you.
Resolved. I don't know if it can help anyone but in my case I had to modify a .conf file on the etc folder. The developer gave me the answer.
I know this has probably been asked many times before, but I still haven't seen an actual fix for it.
My day-to-day development environment is as follows:
1. NetBeans (latest), 2. Glassfish (latest as bundled with NB), 3. JPA, JSF, JAXB, Jersey for JAX-RS
I have about 600 classes in my project, spread across two EJB projects and one WAR project, all inside an EAR.
I am on latest JDK 7 (on OS X) and I am on an hourly basis getting the infamous "PermGen space" bug. Let's say if I am doing 3 incremental re-deploys a minute, I can only work for a short while before either:
Glassfish run out of PermGen space, so I just have to kill the process.
Deployment becomes extremely slow, due to me having increase max permgen space (as one is advised to do from dozens of answers on S.O.)
Often the only solution is to kill glassfish every 30 minute or so. It's definitely due to a bug somewhere that simply loads new classes for every new incremental re-deploy instead of getting rid of the old ones. I thought this was supposed to be fixed in JDK 7?
This has been a long standing bug in the kind of development environment, and I am rather shocked that it's still going on after my 5+ years of Java development. It's just so frustrating and incredibly unproductive.
(Just before anyone suggests increasing permgen space, believe me I've tried that, and the only thing it "solves" is to prolong the inevitable. I've seen redeployments take up to 400 seconds at its worst. Redeployment is supposed to take 5-6 seconds for a project this size, no more.)
EDIT: I ran jmap and jhat on the Glassfish process after the following steps:
Start glassfish
Deploy my EA
Undeploy my EA
Then did a heap dump with jmap
It turns out that all my classes (which should have been unloaded) are still loaded! Hopefully this is useful information to someone reading this...
Surely, that is a bug, and I don't think that there is an easy solution for that. (If there were, probably you have had it already).
What you can try: Use some hot code replacement tool for example JRebel, This way you don't have to deploy all the time, instead this tool watches the changes of the .class files (and even other web resources, if you configure so), and replaces the class definition within the running JVM. Sounds cool, right?
It works as a Java agent, it starts when your JVM starts.
There are 3 drawbacks of this solution: The deployment is a bit slower, it's harder to debug, and it's a proprietary software (but does not cost much)
When developing with Netbeans + Glassfish and using "Deploy on Save" we've found that libraries packaged within an application are not unloaded when the project is re-deployed; this causes GF to slow down and quickly run out of memory.
Try de-selecting "Package" for all compile-time libraries and place those not already in the Glassfish classpath in the domainX/lib directory.
Not sure but this may be related to GLASSFISH-17449 or GLASSFISH-16283.
I have a Java server that I wrote myself running as a service. Right now looks like the application is somehow eating all my drive space at a 1GB per hour rate.
After a stop of the service the disk space becomes available by itself (I'm not deleting anything). From the application I'm not creating any files or writing to disk besides logs or the database but those are not growing so fast.
The big problem with this is that I can't find any file or folder that is eating up all my drive. I don't know if it is a system file that I don't have access to from the explorer or if it's a virus or a JVM bug. I'm using Oracle JVM 64 bit from JDK 7 update 7.
I appreciate a lot any help you can provide me with this. I have never seen something like that before.
Thanks.
Here are the possible pointers:
Check if your disk is full because of other applications (possibly malware)
Check if there are any IO operations from your application
Check if your local repository (like .m2, .gradle/caches) are filling it up during build with transitive dependencies
If possible, add couple of loggers to display the size of your hardisk using new File("/").getTotalSpace(); along with RAM details and watch how they are changing
Finally if nothing works out, try your application in another machine
The auto complete stalls so frequently and for so long, I quit using it altogether.
I've had success with the following using Eclipse (Classic) 3.6.1 on Windows 7 x64.
"A workaround, until the fix is released in 3.6.2 is summarized here: http://groups.google.com/group/android-developers/msg/0f9d2a852e661cba"
(copied for convenience)
"You can replace your /plugins/
org.eclipse.jdt.core_3.6.1.v_A68_R36x.jar plugin with one from
http://www.google.com/url?q=http://adt-addons.googlecode.com/svn/patches/org.eclipse.jdt.core_3.6.1.v_A68_R36x.zip&ei=vg5aTf2RIMrUgAeI-qTvDA&sa=X&oi=unauthorizedredirect&ct=targetlink&ust=1297749446528273&usg=AFQjCNFv7FGlTrnoVhRGE35JPjHxOwI_Bw
and restart Eclipse. Content Assists will be much better. Just try it.
Don't forget backup your original plugins. "
This solved part of my problem.
In preferences, I defaulted all the 'Java->Editor->Content assist' screens and the performance is much improved. Any lag I have now is due to system speed and is negligible. I've gone from minutes to seconds building the suggestion list.
UPDATE: This didn't completely solve my problem, but it got me close. The search continues...
UPDATE: I'm developing in Java for Android using the default packages that are included and any that might have come down during a update(in retrospect, maybe choosing update all in the SDk update might not have been wise). The timing is fairly consistent online and offline. I did a few tests and found the following:
Startup Eclipse and enter a line of code that can use a .toString(). Typing the '.' populates the auto complete within 2-3 seconds. Type a 't' and it takes 70-75 seconds. After that, 10 seconds. Diff objects do the same thing(75 the first time, 10 after that). It's the filtering process that appears to stall. My CPU does not max, Memory is OK, but the program will go not responding till it's done. Any typeahead gets cached and eventually filters the list when Eclipse starts responding.
For me the problem went away when I increased the memory for the vm.
Put this in your eclipse.ini:
-Xms512m
-Xmx1024m
on my 4GB Windows Vista system this would happen A LOT !! (as well as debug issues when looking up variables).
This all went away after I built my new PC with 8GB RAM. I can now run 4 emulators simultaneously and it doesn't have any debug problems any more either. Auto complete with huge lists also works just fine.
it would seem to be just an issue with how much RAM you've got.
I have a java application that I run from eclipse 3.5.
My OS is WinXP(SP2) and the JRE version is 6.05.
I run the application on two identical computers (or so I think) but the application behaves differently on each computer.
The computers are the same Dell Optiplex model with the same amount of memory and have the same GPU.
On the first computer, the application runs flawlessly. However, on the second one the application freezes for a couple of minutes and then returns to run normally.
The strange thing is that the CPU usage on the second computer is not high at all. It seems as though my application does not receive any CPU for no apparent reason.
Computers should be deterministic so I assume there must be some difference between the machines but I don't know where to look.
I would love some ideas on where the problem might be.
Thanks,
Yoav.
I've found the problem.
The application that was unresponsive was run in debug mode.
Sorry to have wasted your time...
It may help you to get a Thread Dump when the app freezes. This will hopefully tell you exactly what is holding you up (i.e. waiting for IO somewhere).
Well, I would first update your JRE version as there are newer versions now.
As for both computers being identical, are they really identical? I find it difficult to believe that both have the same exact software and setup and that anything you have done to one, you have always done to the other. If this is indeed the case, you may want to try to debug your application on the second machine (the one that hangs) and find out specifically where it hangs.
It may also help us if you give more information about your application. The problem may not be your computer at all if the application is doing things like web access, network access, etc.
So both computers have nearly identical hardware. A few other things to check
Do they both have Eclipse 3.5, WinXP(SP2) and JRE 6.05 installed?
And behave differently when run from within Eclipse (on both machines or on one run from command-line)?
Is this reproducible? If yes When does it happen? On startup? Or on some specific action?
Does the program have a GUI?
Is there maybe some kind of virus scanner or another comparable software installed on one of the machines which could delay the program
Is networking, file acccess, multithreading involved?
I can think of two non-application possibilities:
Memory Paging. There's something extra happening on the slow machine, so your JVM is not getting a fair share of CPU time. A large daemon process or some such.
Network access. Your app is making some kind of network call and it's glitching or timeing out. Perhaps going and fetching some XML schema, perhaps a disk acesss to a mounted drive.
I've seen all manner of weirdness when apps attempt to access hosts by name and DNS is not well. One machine has an etc/host entry the other does not. Even each machine might want to resolve itself.