I am curious as to what the average wait time is for the edit/compile/debug/startup cycle for people on various J2EE projects. I have tried to optimize things as much as possible but I I think am still spending too much time waiting to things to startup. My guess it that I spend a total of 2 hours a day waiting for servers to startup and
My team's startup time while developing is usually a few seconds, typically 5 to 20 secs. We are using:
1. tomcat 4.1.12 with it's reload feature, to reload only when needed such as when the java code changes
2. ant, with many different targets for various work
3. custom directory structure
4. custom framework, configurable to work with ejb or without it
5. velocity with cache=false and autoreload=true, we do not do a reload when we change any of our vm files, just an ant target that copies the updates vm files to tomcat
We deploy to iplanet and also tomcat. Before this, we had to wait between 30 sec on the fastest machine to about 2 minutes.
Get JBoss app server. Start it up once. Then hot deploy ear, war, etc by simply having your ant task copy them into deploy directory. Undeploy by having an ant task to delete the file from deploy. Very simple. Takes no time at all.
Hi. About JBoss app server hot deploy. Can you explain how you do it. I have been using JBoss for while. Since version 3.0.1 I cannot do hot deploy of my ear packages. I need to restart JBoss instead. I have follow env. configuration
WAS 5.0 has hot redeploy for EJB JARs and WARs, this should shorten the wait times for WAS users. Just copy the modified EJB.JAR to the appropriate installedapps/xxx subdir and then WAS will stop the app, reload the module and then restarts the app. This works for when binding info doesn't change. The turnaround time for this is pretty short, like under 10 seconds.
You can work this into an ANT script pretty easy and deploy during your build script straight to a local single server WAS.
Install your EAR one time and then you can fix bugs using this approach in ejb-jars.
If you're using WSAD then you get similar support built in to the IDE.
Not long at all - a few seconds. We don't use EJB. Compile/debug time is minimal.
JDeveloper 9.0.3 IDE comes with Embedded OC4J Server which allows to run,debug, and profile EJBs/JSP/Servlets in the IDE itself with hot deployment support.
It cuts down edit-compile-run-debug-profile cycle significantly during the incremental development process.
When the J2EE application is ready, it can be assembled and deployed to AppServer.
Hi, we have a 4000 classes project and we use tomcat and wl ( 10% of the application is written in EJB). It takes a lot of time to startup, re-deploy, or change and it doesn´t work always.
We've been trying to reduce this time but no major improvements where made.
Now it´s just part of our daily work to do other things while Tomcat or WL start up.
Sorry, I can't resist...
- Learn to move your hands and fingers faster
- Buy a faster computer
- Write smaller programs
Now in all seriousness, what kind of app server are you using? I've used Ant's support for Tomcat where when I compile an app Ant will unload the application and deploy the new version, all without having to stop/restart Tomcat. I know JBoss and most commercial J2EE app servers have hot deploy, though it can sometimes take a while for the EAR to be deployed, but I doubt 2 hours. Also, maybe don't redeploy your app with every minor code change. Do you compiles and run JUnit unit tests to see if your small increment changes work, deploy and do system tests later and less often.
I've been working on a large J2EE project comprising several WebLogic instances, some of which boast the dreadful Commerce Server (sucks, by the way) on top.
Hot deployment and Ant scripts make building go without significant delays in the work, but... If you need to add/remove something to/from the "domain lib" folder of a Commerce Server instance, which cannot be done while the server is running, you're up to a 20 minute wait while the Commerce Server is starting up. Starting plain WebLogic takes less than 5 minutes.
The project has 7 digits of LOC, a lot of EJBs, a few web applications, and several data sources.
2 hours ??? I suggest you to use hot redeployment and a fast server. Then you will have an opportunity to sleep
2 hours more in morning :-)
We had JBoss in our project. We didnt need to restart it to redeploy EJB's.
There are many factors here. something as simple as having a couple of JDBC connection pools with a connection attempt delay will draw out boot up time. Check how many initial connections you have and the delay time between establishing each one.
you've already been given advice about hot deployment - this really is a boon - but I'm suprised to hear from Billy that it 'stops' the app when hot deploying - maybe he could expand on this.
We have an application with about 50 beans and it boots reqasonably quickly when the connection pool initial sizes are low.
What about writing an Ant script which compile/generate/package your war/ear and deploy them on a hot-deploy-capable server ?
For developers, local Tomcat and/or Jboss have this functionnality and for free.
One click in the IDE and it is done.
You should not loose so much time when it is easy and free to get a quick and powerful (local) development platform. We are soon in 2003, wake up guyz ! :)
I am using Borland JBuilder and the Borland Enterprise server.
I am compiling the files I am changing right after I finish changing / writing them. I hardly do a "rebuild" on my project.
The deployment cycle is very fast and I never get to wait for it, especially since the stubs are being built while in JB, disabling the stubs generation at deployment time reduces the deployment phase to almost zero time consuming.
(stubs generation in Borland is like the EJBC phase in WL etc..)
Using WSAD 4.03 the test environment does not support hot deployment, updating a class requires shutdown/startup of the test environment. Also included jsp files are not recognised as changed. Hopefully this is fixed in WSAD 5.
But yes WSAD 4.03 wastes many hours.
WSAD 4 is crap! It's full of bugs and I have to restart it every two hours, because it simply stops working, or become so slow that even typing a line of code takes minutes! And to have to restart the server for every change in EJBs is the hell for debugging!
I found that Weblogic 6.x took about 45 seconds to startup with our product and the dev team hated it. We moved to Resin 2.1, it starts up in under 5 seconds with the webapp lazy-init and the dev team is happy again. Whatever you do, make sure you are using the app server's hot redeploy; you should not need to restart the server when changing a WAR. It will save you hours of time.
And that problem is twofold:
1. It is not straightforward/clear how to appropriately design your build process with EJBs that can be quickly rebuilt, but use a variety of similar classes. Most app servers let you hot deploy EJB jars or web-apps, but not random jars containing common classes. Most projects end up duplicating the classes in each EJB jar, and then when you change one of them, sit back for 30 minutes while all your EJBs recompile.
2. It is not obvious how to update your bean implementation without re-running the ejb compiler to generate stubs/skeletons. YOu shouldn't need to rebuild this if you just changed code, but the app server vendors don't provide this function, or they don't make it clear.
Not to mention that ant is a terrible build tool, because it is difficult, if not impossible, to get it to properly determine dependancies between EJB jars and your class files, and to properly rebuild the ones that are out of date. This is almost trivial in make, and with ant it just seems near impossible, since ant is such a bad scripting language.
30 minutes?? I can recompile 20 EJBs in about a minute with Together or JBuilder. I have also designed a method to keep all the common classes in a separate JAR for all EJBs to use, I can reload the JAR and all EJBs will pick up the latest versions. I can also hot deploy these changes to EJBs that cannot be undeployed/redeployed. Again the complete process takes less than a minute.
Agree with you on point 2.
Together, Jbuilder and JDeveloper (have not used it much) have terrific build tools. Together has a utility that will search for dependencies. If you do not want to use these tools, do not know why??, I suggest EJBGen, it lets you define all the properties of the EJB as Java Doc. With the right code templates, this becomes a very simple process.
Well, actually at www.r4.com we're using WLS 6.1 with "no production" mode at production environment.<br>
Now, we're testing WLS 6.1 on Linux Redhat and those are the headlines:<br>
- 40 JDBC connections on 2 Oracle tier-2 pools<br>
- 3 SOAP web services<br>
- 1 mega webapp<br>
- 1 EJB<br>
WLS 6.1 on M$ Win2000 startup: about 15 minutes.<br>
WLS 6.1 on Linux Redhat 7.2: 3 minutes !!!! (great)<br>
Just my 2 cents.<br>
Here we go again, instigating crap. Nevertheless, in development, WL 6.x and 7, about 15 seconds to compile and hot deploy using JBuilder or Together. No need to shut down the server. If I were to shut down and restart the server, maybe 30 to 45 seconds; but we only do that first thing in the morning to have a fresh start.
We design around the problem. Most of our beans are stateless session. The beans have very little logic in them, leaving little need to unit test them. We defer the complexity to classes which are locally debugable and don't need a container. The container is only needed for system testing and beyond.
We are using JRun 2.3.3, which is old version of Macromedia JRun it runs only Web Apps and it does not support class reloading, but at least it recompiles JSPs. It runs as a NT service and restarting it will take probably 30-45 seconds (we do not have any servlets that must be loaded during start up).
We also started to use Tomcat 4.1.12 and its class reloading works great except some special cases when you have static members then you might loose your session when it reloading classes. We do not need to restart Tomcat for long period but even if we need to it will take less then 1 min.
The biggest problem for us is WLS 5.1 which does not supports class reloading and it takes maybe 4-5 minutes for full restart on WinNT 4.0.
To resolve some problems of restarting old servers we are often during development putting classes inside JSPs inside static declaration and when code is tested and tuned we are moving those classes in separate Java file that later got compiled and deployed, so we restart server as less as possible. Plus we are avoiding servlets that must be loaded during server startup.
P.S.: By the way I forgot to mention we do not use EJB at all.
The startup time for the app server on JBOSS is 41 seconds. I use eclipse for coding, so by the time I invoke ant I know that my code will compile.
I have broken up the application into self-contained jars, there is no monster jar that has everything. If I redpoly an EJB JBOSS seems to pick it up. But If I redploy a shared .jar file then it does not seem to be picked up, and I have to restart the server.
So here are the steps, once I have finished changing my code in Eclipse.
1. Switch to a DOS prompt and type ANT
2. ANT will take about 15-75 seconds to do its thing build the current project and check dependencies ... etc. On average its about 25 seconds.
3. Startup JBOSS takes about 41 seconds, down from 3 minutes when we were using WL 6.1
4. Reload some JSP page or something to test new code with, since this is the first time JBOSS will take a little bit longer to convert it to a JSP And compile it. Say 5 seconds.
5. Lag time between seeing that a step has completed and then pushing the process along in another window say bout 3 seconds x 4 steps = 12 seconds
Total Time: 25 + 41 + 5 + 12 = 83 seconds
I like to develop with small increments of code. Say I want to make 20 changes small changes to the code on average per day and I want to compile/build/deploy/test my changes right after I make them. Say it takes 3 tries to get each to work (yeah sometimes its 1 sometimes its 10, especially when you are tying to figure out how some one elses API works) So the total number of full compile/build/deploy/test cycles is about 20 * 3 = 60 per day.
So total time per day spent in the waiting for stuff is like 60 * 83 seconds = 4980 s / 60 s = 83 minutes / 60 min = 1.38 hours
The problem with the development cycle is that none of the individual steps take too much time. However, they take just enough time to be noticeably slow and when you are seeing the same output from ANT & APP SERVER it seems even SLOWER! I think I have read somewhere that if a website takes 8 seconds or more to come back it is perceived as slow by the users. I was happy when we switched from WL 6.1 to JOBSS hey we went from 3 minutes to 41 seconds.
So whenever I am doing J2EE development I always feel like the tools and the technology is limiting how fast I can get stuff done. The fact is that my company is full of people who hate J2EE development because of the whole edit/compile/deploy/restart/business and most of them are highly experienced developers. Statements commonly uttered around the office is "Do you any J2EE programmers that are productive that don't spend a good chunk of the day dealing with trying to get the app server to run?"
I find it enlightening that the people who reported reasonable cycle times seem to be only using JSP/Servlets, and most of their code works outside of / can be tested outside of an APP Server.
Ah and don't forget about the number of seconds you spend check this site and just plain general surfing while your code compliles or your appserver starts.
I've just finnished a moderate size'd struts EJB application. The live deployment platform was SilverStream but development and testing were done in parallel with JBoss (I figured that if the same code worked on TWO differnt app servers it must be ok).
I found the same sort of frustration that you've had. Simple EJB changes ended up with lots of wasted time. I hate to think how this summed up over the project. Even though deployment to SilverStream was far slower than JBoss it was less frustrating for testing as the deployment process in SilverStream compiles all the JSPs and hence the app works at normal speed once if FINALLY is deployed.
Anyhow I was mentioning my frustration to a colleague the other day and he told me that its considered best practice to write test applications to drive any EJBs that you write rather than trying to do this through a web app. Even though this is one more arguably non productive step that we J2EE guys do I think I'll go down that route for the next project that I am doing.
Wait time in our case is 10 minutes for one server with WLS60. We have 4 big was files on web servers.
One thing we notice was caching realm is taking lot of time to cache user infromation. We use database to store user informations.
Things, I think, have certainly gotten much better in the last few years. When I first started with J2EE, it was restart, restart, restart, with looong restart times. But lately I've done devlopment with JRun, JBoss, Resin, Tomcat (all with hot-deploy/class reloading) and Orion (very fast startup). I must say that with these advances, the speed of development is way up.
Well, let's cut the crap. Java is many times a pain. Simple as that. Most of us look for the softer couch and it's not there in Java. I wish it was.
There are guys who love to fix a clunker and others look at the hobby in disbelief. It so happens that Java attracts people that are interested in computer science. They are not bothered by the lack of niceties. It also happens that this industry is filled with people that want to make money just watching the grass grow holding a mouse in their hands and their illustrious managers.
We need both worlds. I'm just mad that Sun brought this wonderful language into the world wrapped up in rags. They are marketing idiots. What Java brings to the developer community is way beyond what many open source tools have done. However, we somehow managed to bring both Microsoft and open source against us.
We need better tools, cheaper. Kudos to IntelliJ. They rock.
I wait 0!
If you use Resin, it auto reloads the class as you change it, and it coplies it.
It also saves the current session information.
Any wait is not aceptable during development.
Also... I use MVC, and used layered component development. Each layer/component is unit tested in a console app. so by the time I start any app. server I am integrating.
Good luck you that wait.
Ed: this is a huge problem IMO and one that I think should drive people to fundamentally alter their architecture approach. These and other concerns are making people more and more skeptical of the whole EJB-is-the-only-way-to-build-an-enterprise-app solution that was conventional wisdom a couple years ago.
I think Rickard Oberg's new AOP/dynamic proxy idea is very cool and is really an EJB alternative - although it's a whole lot more than that.
I was in your position at my last company. We had debug/deploy/test cycles in your range, and for some technical reasons we couldn't use hot deploy. Nowadays I'm adopting a much more XP-ish attitude - starting from zero (well almost zero, almost every enterprise app requires a RDB) and moving out from there.
IMO a big test is, can I step thru the code with a debugger (easily)? Once you get into the write-log-statement-and-restart-appserver-to-see-output method of debugging, something is really wrong, again my opinion. (As an aside, with IDEA 3.0 I can easily run tomcat and step thru servlet code. And if you use Webwork instead of Struts you can unit test your actions without having to run a servlet container at all).
Just another quick thought...I think maybe the worst thing about the long cycles is it breaks your flow of concetration. I change some code, sit there for a couple minutes during compile/jar/deploy/start server, and it becomes so mind-numbing that sometimes it takes me a couple seconds to remember what I was trying to do. Maybe it's just me.
technical reasons we couldn't use hot deploy. Nowadays I'm adopting a much more XP-ish attitude - starting from zero (well almost zero, almost every enterprise app requires a RDB) and moving out from there.
Well, that's not XP, sorry. Not every enterprise app requires an RDB. We just went all the way and threw that out too in favor of Prevayler. If you're serious about doing the Simplest Thing That Could Possibly Work have a look at Prevayler. The idea is so simple that you're initial thought is "this couldn't possibly work". We had a try, and it does.
It's simply amazing how fast we can build stuff nowadays. And if we realize we need an RDB after a while, there will be no problem in adding one at that time. In true XP spirit.
Jon - I totally agree with this approach but when the organization decides it wants to use a reporting tool that depends on an RDB there's not much you can do except work around it.
Also anyone that's interested in seeing something really cool should take a look at Jon's Nanning project and how he integrates Prevayler persistence support as an aspect, very nice.
I'd say about four-five seconds including running all the unit-tests. The test-suite is about 60-70 tests (at the moment) exercising about 95% of the code (measured with Clover).
Unit-tests we run from within IntelliJ (just hit Shift-F10!). We're using Nanning as our AOP-framework (transactions, caching, security and so on, replacing EJB) and Prevayler for persistance.
We've noticed that we stop practicing test-first design when the test-suite hit about 10 seconds. That's when developers start running individual tests and not the entire test-suite every time. Our entire architecture has been optimized for this. As a side-effect we've ended up with one of the most scaleable and performant system I've ever encountered.
Most of J2EE isn't really designed for test-first design. Not for performance either... To be honest I have no idea of what it's been designed for really.
Keep it Simple!
I guess you must be working with Rickard Oberg :)
No one has mentioned Jikes so far. I'd strongly suggest that as long as you don't have any compatibility problems, do all your compiling with Jikes for a significant speed increase. And of course what everyone else is saying about hot deployment etc is very important too.
Our project takes maybe 40 seconds for a complete rebuild and deployment (using Orion), however this is rarely required. With hot deployment and incremental builds, we're looking at maybe 10 seconds or so tops.
J2EE development cycles have certainly been been faster in recent years, but we're still finding that server configuration and the debugging cycle are real problems.
Ensemble Systems has a J2EE development tool kit called Glider http://www.ensemble-systems.com/glider.html
which brings the traditional development paradigm of code, compile and debug back to J2EE (instead of code, compile, configure server, package, deploy, debug).
Our development teams have been using Glider internally on our projects for about 6 months. If you are interested in how that project used Glider and what the performance times were, please refer to:
JUG Glider Presentation.ppt
Glider has helped our teams tremendously throughout the debugging cycle. Glider has an instant-start EJB container and web server which speeds up the debugging cycle considerably. We've also included a Dynamic Debugger which allows us to change code on-the-fly like you would in Visual Basic.
Senior J2EE Architect, Ensemble Systems Inc.