I'm working on a project on Eclipse, more specific RAD build. The EAR file exported is around 40 mb, last week it was taking 1 minute, today its taking more than 10 minutes.
I didnt change much code, nor changed any config related to the JVM.
I export directly from RAD, right click on the project and export EAR.
So whats going wrong?
Thoughts:
Clearly something is different. What could it be?
Your app: Could you now have lots more little graphics files or some such?
Your app: could you be referencing some external resource eg. XSDs from somewhere remote, is it generating code at this point with some such reference?
Environment: Disk drive. Are you exporting to some nearly full disk? Or a network drive that's suddenly really slow, or somehow a revision control system is trying to adopt what you are exporting.
Environment: Memory. I've seen Eclipse get stupidly slow when paging is happening. Could you just have increased your memory usage a tad or now be running something new in the background?
As none of those apply (you really sure?) then I would do this:
take the app to another workspace
take the app to another machine
Break the app down to pieces, binary chop until you find what the expensive bit
The problem is fixed, im not sure which of these fixed it, but one of them did:
The output folder was shared on the network, stopped the sharing
Defragmented the disk
Emptied the Recycle Bin (it had almost 5 GB)
I made them all together, so i not sure which solved the problem, but i suspect one of the first two.
It was a an OS problem, nothing to do with Eclipse.
Related
Basically when I auto complete on Eclipse (By pressing CTRL+Space) the program laggs for about 5 seconds. This is getting really annoying because I use the auto complete alot. How do I fix this?
The workspace I'm working on is located on a NAS with a 1Gbit/s connection. Could this be causing it?
Thanks.
Check if problem exists with local resources too
Create a local workspace and open it with same eclipse instance. Now create a simple java project by new project wizard at your local machine inside this workapce and try code completion there. If it's still slow go to Step 2.
(by the way - I wouldn't store workspace information on remote side, but always local)
Check proposal kinds
If it's not a network issue and the problem still exists on a simple local workplace with local sources you should inspect your proposal setup as shown in next picture.Maybe one of the proposal kinds is slowing down your IDE. You can experiment with turning off proposal kinds sequential to find the problematic one.
System requirements
If you got stil the problem after doing Step 1-2 maybe your system has not enough power/memory to provide eclipse (but normally not the reason - I am using eclipse at Linux on an old T61 notebook with 4 GB Ram + SSD and it works fine!)
I am using Ubuntu (in case it will make a difference) and I am trying use Camel to send files to processor from one folder. But the problem is that when I am saving this file in the folder (takes about 5-10 seconds) Camel picks it up straight away.
To simulate the process I am using gedit with txt file with ~500k rows so it will take some time to save.
I have tried adding options:
from("file:src/Data/new/?readLock=changed&readLockMinAge=3m")
I have tried using
.filter(header("CamelFileLastModified").isGreaterThan(new Date(System.currentTimeMillis()-120000))) to give 2 minute delay.
Nothing seems to influence its behaviour, it picks it up straight away, throws an exception because of some checks while processing file and moves it to the Error folder.
I know there is an issue with FTP file transfers which I will have to face later on, but I can not even get it working on local file system.
Any help will be appreciated!
SOLVED
from("file:src/Data/new/?readLock=changed&readLockMinAge=3m")
Parameters actually work as they should. I was using Jetty to run the project and I should have done whole project clean/install after any amendments.
I had to amend parameters a bit to:
from("file:src/Data/new/?readLock=changed&readLockTimeout=65000&readLockMinAge=1m")
because it was complaining that readLockTimeout should be more than readLockCheckInterval + readLockMinAge.
Have a look into the documentation:
Avoid reading files currently being written by another application
Beware the JDK File IO API is a bit limited in detecting whether
another application is currently writing/copying a file. And the
implementation can be different depending on OS platform as well. This
could lead to that Camel thinks the file is not locked by another
process and start consuming it. Therefore you have to do you own
investigation what suites your environment. To help with this Camel
provides different readLock options and doneFileName option that you
can use. See also the section Consuming files from folders where
others drop files directly.
So I think the doneFileName option will solve your problem.
I tried to reimport my android project on eclipse to solve a problem but I accidently overwrote all my files in the project. All of them had been corrupted which means their size is now 0B...
I tried to use Local History but it's useless since my project is no longer in my workspace, same for .metadata.
I also tried to use Recuva (Software for recovering files) which see my files with their real size but when I try recover them, their size is always 0B...
I lost about 7 days of work and I don't really want to rewrite my code using Java Decompiler...
So my question is, is there any solution to recover that files ?
I wrote 200 lines of code and suddenly system restarted. I lost all code. But I recovered data from eclipse's local history. Right click on the file -->replace with-->previous from Local History
Eclipse has a local history, although by default it's set very low - one of my first tasks when setting up a new development machine is to up the values (in addition to my other version control)
If you do have a history you can right click on your class, and select compare with local history.
You could try decompiling with something like JD-GUI. It might not be as onerous as you think. Obfuscators exist for a reason.
It is not really programming question, but i had similar situation and "Mini Tool Power Data Recovery" tool helped me (it is paid tool, free version exists, but maybe you can search in this direction and find something open source). I tried some another tools then, but with no results.
After adding <item>170,000</items> to string.xml. It becomes so slow in building workspace, I increase my heap space and jvm memory, but is still slow I had to wait 4 hours after every edit to save on eclipse before i think of running the program.
Any solution please? (Am using gnome 3.0 on ubuntu 11.10).
Instead of placing strings in string.xml, why don't you try placing a file inside /res/raw and when the app starts for the first time you insert it into a db?
It's not clear to me exactly what you are doing. How are you building this XML file? Perhaps you are using Java string concatenation? That will certainly be extremely slow. I would do it using something like an XMLStreamWriter. But you need to describe your scenario in more detail, for example I don't see where Eclipse comes into it.
I have a jar. I want the jar to be able to make a copy of itself while running. I understand windows may have problems with this. How would I do this, or am I over thinking it?
Edit: To explain a bit more....
I'm writing a repackagable firmware deployment system... http://code.google.com/p/heimdall-one-click/ The idea is that a ROM developer from XDA can make his own, then pack it up in a cross-platform deployable one-click packaging nearly as easily as it is to deploy the firmware.
My program takes alot of the work out by automating the tasks... I'm trying to automate packaging of the one-click deployable packaging system.... give the developers a form to fill out which will change the header information, then they select their firmware files to be deployed. I'm trying to keep it all in one jar.
As josh says, it would be nice if you tell why do you want to do this in order to help.
Answering only what have you post, copying the jar is just copying another file. There is the issue that it might be blocked by the OS (Windows); another issue is how do you locate it in the machine and if the user running the process has the permissions needed.
Once those two issues are solved, it is just a copy operation, the OS could not care less that if the order to copy comes from the process run from the file or from another one.
EDIT to asnwer changes in the first post.
As I told before, in the end copying a file is a OS issue. If you want to copy the current jar in Windows, then the jar must not be locked by other process so it becomes an OS question rather than a Java one.
Possible workarounds:
The faster (but dirtiest) is to launch a .bat that does a sleep of a few seconds and then does the copy. Immediately after launching it, your close your java app. If you need to continue doing things in Java, after copying the file, the .bat launches the java app again (with the appropiate parameters).
A variant of the previous is slightly sleazier... launch your java app from a .bat, and the first thing that .bat does is copying your jar to the PC temp directory. Be sure to document it well so your users do not get scared!
JNI library to unlock a file. There are several programs that (Unlocker) that try to unlock files; do not know to which point it is effective or how will it affect the JVM.
I believe you can use:
File file = new File(MyClass.class.getProtectionDomain().getCodeSource().getLocation().getPath());
to get a reference to the path to the .JAR file.
Then you just make a copy of it:
http://download.oracle.com/javase/tutorial/essential/io/copy.html
Your operating system might not allow this, but I think it should.