2

We are developing our web application using JAVA GWT-P framework (Version 2.4). We are using Eclipse (Version 3.7) Indigo as a development GUI. While we are debugging the application, eclipse is getting hanged generally and surprisingly this is a random behavior.

And this is not happening in only part of the program. Anytime, while we debug, Eclipse hangs in different module.

To resolve this , we tried to use different Operating system such as Windows XP (development gui: Eclipse version 3.7 Indigo), Fedora Version 16 (with development gui: Eclipse version Helios Service Release 2), Cent OS (with development gui: Eclipse version Helios Service Release 2). But no luck.

Can anyone help me out to decide which OS, and eclipse or version should we have to use so can able to resolve the hanging issue?

Hardik Mishra
  • 14,779
  • 9
  • 61
  • 96
Pratik Vohera
  • 31
  • 4
  • I don't have any issues with this configuration - Windows 7 64 bit(SP 1), 4 GB RAM, Core i5, Java 7 (1.7.0_02), Eclipse Galileo (build 20100218-1602), GWT SDK 2.4, Google plugin for Eclipse 3.5, GWT Designer 2.4.2, Window Builder 1.2.0. – Sree Jul 03 '12 at 07:09
  • try to test your memory hardware.. – Arcadien Jul 03 '12 at 08:33

2 Answers2

1

Use a machine with at least 8G RAM, quad core for GWT development. Anything less than that would be catastrophic and unproductive.

Ideally 8 core, 12 GB.

  • Increase your eclipse jvm vm heap size max, at startup. Default eclipse startup is either 256M or 512M. It should be at least 768M. I have tried 1024M which made only a marginal difference above 768M. I found 900M seems to be the most that would be used in my cases.

  • You may have to increase your permgen memory allocation too. I think permgen space is used for storing class definition and are never garbage-collected. I presume that when my eclipse hung indefinitely was when there was no more permgen space to store new class defn.

I have never had to redefine the stackspace allocation for eclipse.

You can google around to find out the jvm startup arguments to define mem allocation. e.g. -Xmx, etc.

  • Initially develop only for a single browser. Decide between using FF or Chrome as your dev browser. Then tune your entrypoint gwt.xml to set the user-agent property for that browser. Google on gwt set property user-agent. Compiling for only one browser, I have found, speeds up the compilation a lot.

  • Don't ever store your projects, source files, resources or libs that are accessed by the compiler, in a network or usb drive. All your compilable/includable resources should be on your local drive.

Try to use maven or some other tool for dependency management, so that you do not need to access your jars or dependent projects over the network.

  • Do not, ever, let your development strategy roll down the hill by depending on live-project dependencies. Having workspace with 50 or more projects is disaster and signifies a development team in crisis. The compulsive and persistent compilation, scanning of projects by eclipse background take a huge toll on the performance of eclipse.

  • Try to disable as much validation as possible. e.g., disable html and javascript validation.

If you have a huge number of server side projects ... You need to re-architect your development strategy to cluster your 50 - 100 projects into project packages, so that each project package has no more than 20 compilable/validateable project members (ideally less than 5 projects). Each package is frozen by versions and packaged as jars. Use only the jars for development dependencies.

Your programmers need to learn not to have the impulse to work on a workspace with 200 projects. Enhancements are reserved for bugzillas of each project package. Having a 200 project workspace is bad project management. It wastes your programmers' time by having eclipse slow down now and then.

  • Have sufficient temp space (or for Windows sufficient slack space on the user disk). I have experienced that insufficient disk space for compiler buffering/caching has caused slow-downs and hang-ups. Having a 5G slack space is the minimal - the more the merrier so as to preclude having to clear the trash or search for files to delete or clear the GWT compiler generated temp files. A 5G slack space is still very inconvenient.

AFAI have experienced, neither windows 7/vista or linux made much performance difference except that eclipse seems to start up much slower on Windows.

  • Therefore, if you know how to tune your anti-virus, may be you should tell the anti-virus software to skip scanning the workspace and project folders.

  • Unless you have an 8-core 12GB machine, you should disable most of windows aero, trasparency. But you need to keep windows compositing (otherwise you would destroy your eyesight looking at the bad fonts).

Blessed Geek
  • 21,058
  • 23
  • 106
  • 176
  • 1
    Not many people can afford an 8 core 12 GB machine for development. For a production server it's fine. I am doing GWT on eclipse with just 4 GB RAM 64 bit Windows 7. – Sree Jul 03 '12 at 07:00
  • I got a core2 duoE4600 with 4G. It works but i stopped using the windowbuilder. Quite unusable with Windows XP, i switched to Ubuntu which is many much more efficient with older config. – Arcadien Jul 03 '12 at 08:32
  • @sreehari I agree with you. As not many people can afford 8 core 12 gb machine for the development. We can try out with the 4 GB RAM 64 bit machine and will check out for the difference.. – Pratik Vohera Jul 05 '12 at 05:30
  • @Blessed Geek We can try to check out with the tweaks that you said in the post. Thanks for your reply. Will post it once I done with the tweaks. – Pratik Vohera Jul 05 '12 at 05:30
1

THE PROBLEM

I have a GWT project that worked fine on my old core2 machine. When I recently got a new core i7, 8GB ram (Dell XPS Ubuntu developer edition), I discovered that Eclipse hangs VERY OFTEN (about 90% of the startups hang) when I try to start debugging by clicking the browser link under the "Development Mode" eclipse view. There MUST be a thread synchronization bug (deadlock) that can only happen when the 'timing is different' from normal test cases. This fact that it's a timing bug deadlock is why it appears so "random" and has not yet been discovered and fixed. I have all the LATEST GWT at the time I'm writing this, and latest Eclipse etc.

THE WORKAROUND:

Luckily I discovered that if I copy that link and paste it into an already started instance of Firefox (outside eclipse) then there is never any hang. I'm 100% certain that this is not a problem in my code. I'm 95% certain it's a deadlock happening in GWT. So just don't click the "Development Mode" link and you'll be fine. Hope to have helped someone with this post.

  • You probably have a ulimit problem on your machine. Check ulimit -n, or ulimit -a. If you have a soft file limit under 2048, it's your fault, not gwts :) – Ajax Oct 25 '13 at 14:05