This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hi, I was wondering if anyone has tips on improving the load time of a J2EE EAR file in WSAD 5.x.
Our EAR project has many referenced projects, and although most of them are in binary form, the load time, especially in debug mode, take a really long time; 5 minutes or more.
An IBM WSAD redbook mentioned manipulating the heap allocated to the WSAD server JVM and the workbench JVM as a way of fine tuning performance. But I had no luck doing so, in fact at one point the WSAD debugger stopped working correctly.
Anyway, I'd appreciate anyone information regarding large EAR files in WSAD.
Thanks for the reply; I guess I wasn't clear enough.
The load time I am referring to is the time from when I select the ear project and chose "Debug on Server" until I get the "Open for business" message. This the time I am trying to reduce. The reason I am trying to reduce this time is that in a develop/debug environments, you can loose a considerable amount of time waiting for restarts of the debugger.
Also, the binary form projects are kept as jars. Mind you, the number of projects are in the hunderds (~400 or so). Even if I removed the stand alone projects and only kept the common components, I still have a considerable number of projects referenced in the EAR.
I'm going to be looking into the hot deployment feature in WSAD 5.1.2, but I was wondering if there are any other techniques out there.
Mohsen, Yes it does. This was actually the case in WSAD 4 as well. It's just that the time difference is larger in WSAD 5.
Joined: Aug 27, 2002
In that case I am not sure if I understand your previous recommendation. Can you expand on that please? Also, I thought the EARs were bound to the server, how can I start the server without loading the EAR/WAR projects???
Mohsen, When you start the server in either mode, it loads the EARs attached to it. In particular it binds the JNDI names, checks datasources, etc. After each step, it gives some of the memory back. At some point, it needs to run the EJB/WAR. At this point, the server loads the appropriate module and all dependencies.
By starting the server (along with the ear) and not explicitly requesting a module, you are putting a break between the two steps. This allows the JVM to reclaim some memory. That way by the time you do processing more memory is available. The less disk accesses/paging that occurs, the faster things go.
Everything I've said so far applies to debug mode or regular mode. It's just that debug mode uses a lot more memory. Therefore the effect is more prounounced. It may or may not be enough of a difference for your application. Try it. It doesn't cost anything and you may be surprised by the results!