Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time
September 22nd, 2009 by Jevgeni KabanovA couple of months ago we ran a survey asking a few questions about Java EE development, containers and redeploy times. Now that over 1100 people have responded it’s time to update the results. Since we’ve had more time to analyze them we also hope to provide a few insights into the data including a more detailed container breakdown.
If you’d like to play with the results on your own we‘ve provided all the data and our calculations in a handy Excel sheet that you can download here. As a note, if you haven’t answered the 3-question survey yet, take two minutes and go for it. As more answers trickle in we’ll update this post with the new data.
The first question in the survey was “What container do you use on your largest current project?”. The breakdown follows:
Chart 1: Which Container is used most often?
We didn’t include the containers that scored less than 10 answers in the survey. These included:
- (2) Adobe JRun
- (1) Geronimo
- (1) Iona
- (7) TmaxSoft JEUS
- (5) JONAS
- (1) Pramati Server
- (4) SAP NetWeaver
- (2) Sybase EAServer
Unsurprisingly Apache Tomcat holds the lead, closely followed by JBoss. Together the OSS servers total over 70% of the responses. Although I wouldn’t go as far as to translate these numbers directly into market share, we did find studies that found similar results, courtesy of SD Times – Slight differences though: we asked which ONE container you use for your largest projects, and theirs appear to allow people to choose multiple containers.
The 2nd question we asked was, “How long does it take to restart your container and redeploy your app?”. The breakdown follows (the horizontal axis is in minutes):
Chart 2: “How long does it take to restart your container and redeploy your app?”
We previously assumed that the redeploy/restart phase lasted approximately 1 minute. Though 38% of respondents agreed or said it was quicker than 1 minute, 62% suggested that this process lasts around 2 or more minutes. The calculated average is approximately 2.5 minutes –indicating that we underestimated the amount of time spent on the redeploy phase.
Moving along, we asked, “In an hour of coding, how many times do you redeploy?”. The breakdown follows:
Chart 3: “How Many Times do you Redeploy in an Hour of Coding?”
The distribution seems to be close to normal, excepting the jump in the end. The average is slightly over five times an hour, which coincides with the measurements we did before.
For those who answered, “I never redeploy”, we asked some of them how they did this. Responses were:
- “I’m not the guy that does the redeploys”
- “We develop on embedded jetty & activemq & atomikos in debug mode instead of nearly unusable target OracleAS. So of course we need redeploy or restart jetty as usual, but not the OAS.”
- “I’m in the very early stages of a project so a lot of out time is spent coding and testing without redeploying – typically I redeploy 3-4 times per hour”
- “We use JavaRebel and it’s awesome” (this obviously came from someone trying to charm our development team – who are still blushing. Note – it’s now called JRebel.)
Next we did some data crunching. We assigned numeric values to each of the intervals (e.g. “3.5″ for the “3-4″ interval) and multiplied the number of redeploys an hour by the amount of time one redeploy takes (basically, Chart 2 times Chart 3), thus finding the approximate amount of time respondents spend redeploying in each hour of development. We broke down the data into five minute intervals:
Chart 4: How Much Time Does a Java Developer Spend Redeploying in an Hour of Coding? (using raw data before improving accuracy)
The average is about twelve and a half minutes per hour, accounting for more than 20% of total development time. However, the standard deviation is over 14, which means that the actual per cent varies greatly. We wanted to show more accurate data, so by looking closely and grouping results, we found this:
- Less than 5 minutes an hour. Looking into this group we see that it is slightly skewed by the respondents who indicated that they never redeploy. We asked the people who “never redeploy” how they do it (see comments above), and they indicated that their responses were often not effective for tracking the actual redeploy time that we are trying to measure. Therefore, it makes sense to remove that data from the chart.
- 5 to 15 minutes an hour. 45% of respondents fall into this category.
- 20 to 25 minutes an hour.
- Over 30 minutes an hour. Looking closer at the data we see that some of the respondents indicated that they redeploy over 60 minutes an hour (choosing both “More than 10 redeploys per hour” and “More than 5 minutes per redeploy” for Charts 2 and 3). This is quite impossible. In fact, we believe any number over 40 minutes per hour seems to be against reason. It makes sense to remove all this data from the chart too.
The chart with the updated data looks as follows:
Chart 5: How Much Time Does a Java Developer Spend Redeploying in an Hour of Coding? (more accurate data)
The average is now ten and a half minutes per hour with a standard deviation of 8, which is more trustworthy. This translates to about 17.5% of total development time, which is considerably more than we expected. We will use this “cleaned up data” for the rest of the post.
Later we’ll describe how to calculate this over a year, but here are some quick figures:
- 5 mins per coding hour becomes 6000 minutes annually (2.5, 40-hour workweeks)
- 9 mins per coding hour becomes 10800 minutes annually (4.5 weeks)
- 14 mins per coding hour becomes 16800 mins annually (7 weeks)
- 21% of respondents report spending more than 14 mins per hour on redeploys
- 71% of respondents report spending more than 2.5 full weeks per year, redeploying.
After looking at this issue in general, we investigated the data on a per-container basis. This is what we found:
Chart 6: Organized By Container, How Much Time is Spent Redeploying?
There are few surprises here. Jetty is leading the pack with only 5.8 minutes per hour spent redeploying and IBM WebSphere is trailing with more than twice more — 13.8 minutes per hour. One thing to note is that although Jetty startup is undoubtedly faster than IBM WebSphere it is likely that most of the difference is due to the size of the applications deployed and the technologies used in them.
Next we have the same chart, but numbers displayed as a percent of development time (time spent per hour divided by 60). Perhaps it’s useful to describe how we define “Development Time”. For us, Development time is what you spend actually writing code, with an IDE, running your server and the Java language. This doesn’t include meetings, gathering requirements, smoking or any other activities that don’t involve a compiler. We’ve asked around, and it sounds like the industry assumes that 5 hours per day are spent coding.
Chart 7: Organized by Container, What Percent of Development Time is Spent Redeploying?
To put those numbers in perspective we can also calculate the amount of time spent redeploying a year. To do that, we’ll make some assumptions:
- We assume 48 work weeks per year. If you’re lucky enough to get more than 4 weeks of vacation, don’t rub it in.
- We assume that 5 hours per day is spent doing development. The other 3 hours are reserved for non-development activities.
The following chart displays the number of 40-hour work weeks a year spent redeploying:
Chart 8: How many 40-hour work weeks are spent on the redeploy phase, over a year?
Depending on the container, we’re looking at 3 to 7 work weeks per year, spent exclusively on the redeploy phase. The average over all of the data is slightly over 5 work weeks a year, but the standard deviation of 4 makes the range of 3-7 more reliable.
Our final graph shows the amount of time spent redeploying per container in more detail. Instead of using averages, we break down the proportion of respondents that redeploy into groups: less than 5 minutes an hour, 5 to 14 minutes and hour, 15 to 29 minutes and hour and over 30 minutes an hour. We expect that this may show the size of projects that use different containers, and potentially shed light on the time your project spends redeploying.
Chart 9: Java EE container market penetration.
We interpret this chart as:
- Jetty is only used in projects that redeploy quickly. This makes all kind of sense, considering that Jetty doesn’t even support redeployment and instead has extremely fast container startup.
- Apache Tomcat and GlassFish are used in same types of project. Both are posed as fully functional yet lightweight alternatives to the classic heavy application servers. Although Tomcat is much more popular today, GlassFish is growing in popularity in the same market share.
- JBoss, Oracle Weblogic and IBM WebSphere compete for pretty much the same market segment. The majority of their projects are large and complex, and the redeploy times reflect that.
- Another interesting fact is that the proportion of projects in the 5-14 group is pretty stable for all containers. This likely corresponds to medium-sized projects that are not actively contested by either lightweight or classical application servers. The only exception is Jetty, which is heavily skewed to the lightweight side.
Coming up next: We’re taking a look at incremental build times and comparing Ant, Maven, Eclipse, IntelliJ, and NetBeans. If you’re interested, take a minute to participate here. Thanks!
September 22nd, 2009 at 4:32 pm
I wish you guys could also solve my “deploys” in Android development….then my (programming) life would be set.
September 22nd, 2009 at 5:22 pm
@Henry What are the redeploy times for Android emulator?
September 23rd, 2009 at 12:41 am
As a Jetty committer it’s nice to see our efforts to keep jetty small, fast and flexible are paying off!
One thing I have to correct though is that Jetty does indeed support redeployment. In fact we support it 4 ways: in the standalone container via our ContextDeployer, in the maven jetty plugin, via jmx using the WebAppContext mbean and programatically when running jetty embedded.
cheers
Jan
September 23rd, 2009 at 7:55 am
The comparison of containers based on how much time developers spend on redeploying them is rather misleading — that assumes that the frequency of redeployment is independent of container. Here’s a breakdown of average deployment time for the deployment systems. Caveats about project size still applies, of course – would have been nice to know the number of classes/number of beans/other size measurement.
Server Redeploy average
Jetty 1,153
Apache Tomcat 1,669
Caucho Resin 1,735
GlassFish 1,900
JBoss 2,705
Oracle OC4J 2,924
Oracle Weblogic 3,606
IBM WebSphere 3,845
September 23rd, 2009 at 7:57 am
@Jan
Thanks for the correction and the speedy container!
September 23rd, 2009 at 8:36 am
@Lars
Not sure if there’s a big difference in the lineup. Plus why would frequency of redeployment depend on container?
September 23rd, 2009 at 1:58 pm
If your compile-deploy cycle lasts more than 10 seconds, you’re doing it very wrong. Make your war smaller and more modular, use a IDE plugin for deployment, use lazy initializations, and separately-deployed resource pools.
September 24th, 2009 at 10:43 am
So those who choose Weblogic and Websphere not only choose to pay Oracle/IBM instead of get free software, they choose to waste developers’ time as well. The good old fashioned “choosing IBM won’t get you fired” turns out to be irresponsible incompetent choice. These companies deserve to suffer…..
September 24th, 2009 at 10:48 am
@searchfull: Ever work with Websphere? 10 seconds doesn’t even get you past the first steps in deployment. Deploying on websphere has sometimes taken me up to half an hour, for something I would consider a smallish app. Even with perfect optimization, you’d be lucky to get your deploy time under 5 minutes.
Not to mention the number of times a clean restart is required, even though IBM would like you to believe it never is…
September 24th, 2009 at 1:42 pm
We’re using Websphere and we don’t redeploy at all. We run in debug mode, using RAD from within our workspace.
Whatever changes happens are deployed automatically by WAS for Java classes and JSPs. Even for EJBs.
We only have to restart the server if we change an EJB’s method’s signature, which is rarely.
Restart time takes about a minute or two, max. Is that an issue? Of course not.
September 22nd, 2009 at 2:33 pm
Survey Results: The Java EE Container Redeploy & Restart Report http://bit.ly/2×542E
This comment was originally posted on Twitter
September 22nd, 2009 at 2:48 pm
Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time http://bit.ly/qgUST
This comment was originally posted on Twitter
September 22nd, 2009 at 2:55 pm
You know, I’m pretty sure that “trustworthier” isn’t a word. http://bit.ly/4xcVx
This comment was originally posted on Twitter
September 22nd, 2009 at 3:23 pm
Java EE Container Redeploy & Restart Report – measuring Turnaround Time http://bit.ly/1clgDN #java #programming #ops
This comment was originally posted on Twitter
September 22nd, 2009 at 4:03 pm
http://bit.ly/114tmh
This comment was originally posted on Twitter
September 22nd, 2009 at 6:19 pm
Good survey on J2EE container redeploy and restart times. I would really like to know what tools these users are using. http://tr.im/zqin
This comment was originally posted on Twitter
September 22nd, 2009 at 7:15 pm
I use an ant redeploy task for tomcat, and it occasionally tomcat stops working and I have to restart it manually. Am I doing something wrong? Does anyone else experience this?
This comment was originally posted on Reddit
September 22nd, 2009 at 7:16 pm
This article is funny. It takes the assumption that the developers redeploy and restart their development web server with each new addition. I won’t say that doesn’t happen as I’ve had to hit more than one programmer up side the head for doing this.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:19 pm
Logs show anything good then? My guess is OOM PermGen
This comment was originally posted on Reddit
September 22nd, 2009 at 7:20 pm
From the article > The average is slightly over five times an hour, which coincides with the measurements we did before.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:25 pm
>Am I doing something wrong? I have a far simpler way using Eclipse and Tomcat. 1. I create a web-root folder in my project. This serves as the root of the web application. 2. I set up my project class output in Eclipse to go to my web-root/WEB-INF/classes folder. 3. I edit the web applications context xml file and set the docBase to point to the web-root folder. I set "reloadable" to true and debug to ‘1′. Now whenever you edit a java file and hit Ctrl-S in Eclipse it should compile it and place it in the web-root/WEB-INF/classes folder automatically. Tomcat will pick up the change. Same with JSP, HTML, etc. You never have to deploy to or restart Tomcat.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:28 pm
What a waste of time. Those programmers are idiots for not doing it properly. I never restart Tomcat or deploy to it when I make changes in development.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:29 pm
How much time do you spend redeploying? Here are some stats:http://is.gd/3zw9n
This comment was originally posted on Twitter
September 22nd, 2009 at 7:32 pm
We develop using debug mode and tomcat. Using Reload classes in IntelliJ IDEA takes somewhere around 10-20 seconds for 4-5 classes. I don’t really see it as an issue.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:36 pm
But does it allow removal/addition of methods, fields and other things [allowed by JavaRebel](http://www.zeroturnaround.com/jrebel/comparison/)? I atleast see use for JavaRebel based on my normal development patterns: If I refactor some code or add parameters to a method, I need to redeploy to effect the changes.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:41 pm
It does not. On the other hand, if I’m developing something running in a container that I need to reload regularly, I don’t do refactoring. I wait until I’ve shut down the container.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:44 pm
Had time to read this while I was redeploying.
This comment was originally posted on Reddit
September 22nd, 2009 at 7:48 pm
This just means that redeployment happens automatically when you make the change, you still have to wait until application initializes.
This comment was originally posted on Reddit
September 22nd, 2009 at 8:02 pm
programadores J2EE perdem de 3 a 7 semanas de trabalho por ano com deploy =) http://bit.ly/4xcVx
This comment was originally posted on Twitter
September 22nd, 2009 at 8:08 pm
I’ve gotten that, although I think I’ve also had other errors. It’s been behaving recently so I don’t remember. I looked up the oom permgen error, and it looks like it’s mostly issues of threaded resources not cleaning up after themselves. Considering the poor treatment of concurrency I’ve seen in our code, I wouldn’t be surprised if this was the issue.
This comment was originally posted on Reddit
September 22nd, 2009 at 8:09 pm
programadores J2EE perdem de 3 a 7 semanas de trabalho por ano com deploy =) http://bit.ly/4xcVx (via @fmeyer)
This comment was originally posted on Twitter
September 22nd, 2009 at 8:10 pm
>This just means that redeployment happens automatically There is no redeployment since there is no deployment to begin with.
This comment was originally posted on Reddit
September 22nd, 2009 at 8:13 pm
The most you can blame memory leaks. A redeploy means that the old classloader is dropped and a new one created and the new one loads all the classes of your app. If the old classloader is not successfully dropped (live objects under it after the GC) then the old classes will be held in memory. The permanent generation holds meta-data describing user classes and it keeps growing as you deploy more "new classes". At one point you get this special OOM.
This comment was originally posted on Reddit
September 22nd, 2009 at 8:18 pm
No tempo livre usam Python ou Ruby? RT @fmeyer programadores JEE perdem de 3 a 7 semanas de trabalho por ano com deploy http://bit.ly/4xcVx
This comment was originally posted on Twitter
September 22nd, 2009 at 8:18 pm
What takes so long in a redeploy? Compiling, copying stuff to a deploy directory, restarting the sever, I forget what else. What’s taking so long? /not a java dev
This comment was originally posted on Reddit
September 22nd, 2009 at 8:20 pm
J2EE users wasting time 3 to 7 work weeks per year #programming http://bit.ly/m5jCf
This comment was originally posted on Twitter
September 22nd, 2009 at 8:40 pm
Reddit/p: J2EE users wasting time 3 to 7 work weeks per year http://bit.ly/oRgih
This comment was originally posted on Twitter
September 22nd, 2009 at 8:44 pm
programadores J2EE perdem de 3 a 7 semanas de trabalho por ano com deploy =) http://bit.ly/4xcVx (via @fmeyer) [eu já sabia !]
This comment was originally posted on Twitter
September 22nd, 2009 at 8:49 pm
3-7 weeks? That’s all?
This comment was originally posted on Reddit
September 22nd, 2009 at 9:12 pm
I wonder how many people put down how many times they redeploy in their development environment vs how long it takes to redeploy in the production environment. I’m not too familiar with the technology, but I’d guess the time to redeploy a test setup is much smaller than a production setup.
This comment was originally posted on Reddit
September 22nd, 2009 at 9:15 pm
the amount of time i waste redeploying doesn’t come anywhere close to what i waste reading articles like this on reddit…
This comment was originally posted on Reddit
September 22nd, 2009 at 9:21 pm
http://bit.ly/2×542E “The Java EE Container Redeploy & Restart Report – measuring Turnaround Time.”
This comment was originally posted on Twitter
September 22nd, 2009 at 9:23 pm
Oh noes! This might actually force me to take a break and surf reddit. (Luckily, our redeploy cycle is 90 seconds max (server debug mode) and only if hotdeploy fails).
This comment was originally posted on Reddit
September 22nd, 2009 at 9:31 pm
J2EE devs spend 10-23% or 3-7 weeks/yr redeploying apps http://is.gd/3zHmj
This comment was originally posted on Twitter
September 22nd, 2009 at 9:38 pm
Tomcat will internally redeploy (servlet context restart)
This comment was originally posted on Reddit
September 22nd, 2009 at 9:50 pm
The context is destroyed and any new classes are loaded in the application classloader. Operation takes around 3 seconds (give or take with your hardware or having too much crap in memory). We can argue over semantics of what a redeploy is but it won’t change that the article is incorrect in its timings.
This comment was originally posted on Reddit
September 22nd, 2009 at 9:57 pm
J2EE devs spend 10-23% or 3-7 weeks/yr redeploying apps http://is.gd/3zHmj (via @dnene)
This comment was originally posted on Twitter
September 22nd, 2009 at 10:05 pm
Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time http://is.gd/3zKWz #java
This comment was originally posted on Twitter
September 22nd, 2009 at 10:14 pm
You think we just sit on our hands while redeploying?
This comment was originally posted on Reddit
September 22nd, 2009 at 10:32 pm
Of course it is incorrect, they are trying to sell something.
This comment was originally posted on Reddit
September 23rd, 2009 at 12:03 am
I tried to see how exactly they calculate that, but it appears that they make no allowance for correlation between speed of deployment and frequency of deployment and instead just multiple averages. For example, I will bet you a rather large sum that the ones who deploy on average > 10 times per hour are *not* those for whom deployment takes > 6 minutes ;-)
This comment was originally posted on Reddit
September 23rd, 2009 at 12:11 am
Worth noting that this survey is conducted by a company that sells a product to avoid redeployment. In other words they have a strong vested interest in producing misleading results.
This comment was originally posted on Reddit
September 23rd, 2009 at 12:44 am
Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time | ZeroTurnaround.com http://ff.im/-8yk6g
This comment was originally posted on Twitter
September 23rd, 2009 at 1:09 am
It’s a pity there isn’t an open-source equivalent to JavaRebel (or that the same functionality isn’t available in the JVM), because JavaRebel is really, really good. It seriously saves me quite a lot of time. NB: I’m not associated with JavaRebel or their company or whatever. I’m just a user.
This comment was originally posted on Reddit
September 23rd, 2009 at 1:19 am
Interesting study showing how much time devs waste doing deploys in JEE. This why I love MyEclipse’s hot code deploy http://bit.ly/2×542E
This comment was originally posted on Twitter
September 23rd, 2009 at 1:33 am
Thats not too pleasant to hear RT @programmingjoy: J2EE users wasting time 3 to 7 work weeks per year #programming http://bit.ly/m5jCf
This comment was originally posted on Twitter
September 23rd, 2009 at 1:55 am
Hoping for a class action lawsuit against J2EE vendors for all the developer time wasted over the last decade: http://bit.ly/1clgDN
This comment was originally posted on Twitter
September 23rd, 2009 at 1:56 am
Java the productivity booster.
This comment was originally posted on FriendFeed
September 23rd, 2009 at 2:09 am
J2EE developers spent average 3-7 work weeks per year on deployment http://bit.ly/1clgDN
This comment was originally posted on Twitter
September 23rd, 2009 at 2:28 am
programadores J2EE perdem de 3 a 7 semanas de trabalho por ano com deploy =) http://bit.ly/4xcVx (via @fmeyer)
This comment was originally posted on Twitter
September 23rd, 2009 at 2:51 am
♻ @fmeyer: programadores J2EE perdem de 3 a 7 semanas de trabalho por ano com deploy =) http://bit.ly/4xcVx
This comment was originally posted on Twitter
September 23rd, 2009 at 4:35 am
How much time is wasted developing in JEE? http://bit.ly/X15Ih
This comment was originally posted on Twitter
September 23rd, 2009 at 5:26 am
This is NOTHING compared to Visual Studio 2008 with Resharper and a semi-big web project. The slightest code change take 1 minute to redeploy to the IIS. Apparently, IIS has to "flush the app domain" and reload EVERYTHING. Plus that every first access to a page takes additional times because of the compilation of the aspx to code. C2D 1.8GHz, 4GB RAM
This comment was originally posted on Reddit
September 23rd, 2009 at 6:08 am
Et après ça, on se demande pourquoi j’ai démissionné? Fallait pas m’obliger à utiliser Websphere… http://yoolink.to/2oi
This comment was originally posted on Twitter
September 23rd, 2009 at 7:10 am
Awesome, you’re quite lucky with your appsize/container/frameworks. Your servlet context restart, IOC framework initialization, ORM framework initialization, warming up caches takes 3 seconds. I’ve worked on telco projects that redeploy for over 10mins.
This comment was originally posted on Reddit
September 23rd, 2009 at 7:38 am
And that’s why the raw data and all our calculations are freely available.
This comment was originally posted on Reddit
September 23rd, 2009 at 7:38 am
Man — so wrong — if we produce misleading results, we’d get baaaad coverage, and have lots of unhappy folks complaining about it. Instead, we took the actual data that we used, showed our calculations, and made the data available to the public for your own use. Check out the sentence at the top that says, "If you’d like to play with the results on your own we‘ve provided all the data and our calculations in a handy Excel sheet that you can download here."
This comment was originally posted on Reddit
September 23rd, 2009 at 7:40 am
Excel sheets with data and calculations are available. We multiply these numbers per response.
This comment was originally posted on Reddit
September 23rd, 2009 at 7:43 am
But in which direction? If they say everyone spends 25% of their time redeploying, it would make it harder to sell product to those only spending 15% of their time. If they say the average is 10%, then their investors will question the need for their product and cut their funding.
This comment was originally posted on Reddit
September 23rd, 2009 at 7:55 am
It’s a lot easier when we just show the numbers that the 1100+ respondents gave us. Then we don’t have to worry about spin, investors, people who don’t mind that their times are above/below the avg, etc. The process looked something like this: Announce survey – get results – show results :-)
This comment was originally posted on Reddit
September 23rd, 2009 at 8:00 am
Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time http://bit.ly/qgUST
This comment was originally posted on Twitter
September 23rd, 2009 at 8:01 am
> J2EE users wasting **50 to 52** work weeks per year FTFY. ;]
This comment was originally posted on Reddit
September 23rd, 2009 at 9:42 am
When I worked with Java this was the case. The thing that took the longest time when starting up the app was probably waiting for Hibernate and Spring to initialize.
This comment was originally posted on Reddit
September 23rd, 2009 at 10:51 am
JavaEE developers spend 20% time redeploying http://bit.ly/114tmh
This comment was originally posted on Twitter
September 23rd, 2009 at 11:43 am
If your compile-deploy cycle lasts more than 10 seconds, you’re doing it very wrong. Make your war smaller and more modular, use a IDE plugin for deployment, use lazy initializations, and separately-deployed resource pools.
This comment was originally posted on Reddit
September 23rd, 2009 at 11:48 am
In europe, only 47. Just sayin’ :)
This comment was originally posted on Reddit
September 23rd, 2009 at 12:01 pm
JEE Developers spend 3 to 7 weeks per year exclusively on the redeploy phase. http://tinyurl.com/lpxj6o
This comment was originally posted on Twitter
September 23rd, 2009 at 12:06 pm
Multitask, evilbit!
This comment was originally posted on Reddit
September 23rd, 2009 at 12:30 pm
JEE Developers spend 3 to 7 weeks per year exclusively on the redeploy phase. http://tinyurl.com/lpxj6o (via @josepapo)
This comment was originally posted on Twitter
September 23rd, 2009 at 1:13 pm
JEE Developers spend 3 to 7 weeks per year just redeploying their apps. http://tinyurl.com/lpxj6o
This comment was originally posted on Twitter
September 23rd, 2009 at 1:22 pm
For a while my group was required to use Rational Software Architect 7.5 with WAS6.1 running locally, I don’t know if it’s because of a gross misconfiguration or what, but there doesn’t seem to be any way to apply changes to jsps or java code without bringing the local server to a complete stop and restarting. Which takes over 5 minutes on a good day.
This comment was originally posted on Reddit
September 23rd, 2009 at 1:58 pm
Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time | ZeroTurnaround.com http://bit.ly/PmTjD
This comment was originally posted on Twitter
September 23rd, 2009 at 2:57 pm
That is because you had it set up incorrectly. See my instructions above.
This comment was originally posted on Reddit
September 23rd, 2009 at 2:58 pm
The Java EE Container Redeploy & Restart Report – measuring Turnaround Time http://tinyurl.com/lpxj6o
This comment was originally posted on Twitter
September 23rd, 2009 at 3:09 pm
Tomcat (all containers) must be restarted if you change a method signature. The JVM simply will not hot-swap that change in. I’m hoping someone chimes in and says, "JRebel" does this" (the video shows explicitly this scenario) and explains how. (Managing the ClassLoader?)
This comment was originally posted on Reddit
September 23rd, 2009 at 3:27 pm
>Tomcat (all containers) must be restarted if you change a method signature. Nope. Read about the "reloadable" attribute for the application context in the Tomcat API. I’ll quote it for you: "Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications." I can explain this in more detail if you are still confused on how it works. >"JRebel" does this" Please peddle products elsewhere.
This comment was originally posted on Reddit
September 23rd, 2009 at 4:07 pm
Les développeurs JEE passent en moyenne 5 semaines par an à attendre le reboot de leur serveur de dev o/ http://bit.ly/JHwqD
This comment was originally posted on Twitter
September 23rd, 2009 at 4:30 pm
GlassFish fares well in redeployment time. Wonder how our rapid redeploy in GlassFish v3 impacts the results! http://tinyurl.com/lpxj6o
This comment was originally posted on Twitter
September 23rd, 2009 at 5:11 pm
Oh God the memories! At one of my previous jobs they used a proprietary framework running on their own customized J2EE server (not on that list) that somehow managed to take 20-30 minutes to start up. And would require a restart for every. single. Java. change. The configuration was obviously broken, though no one ever figured out how to fix it. It was the worst environment I’ve ever worked in. Before I got there, one guy had already been fired for, in part, restarting his server too often. Needless to say, the attrition rate there was very, very high.
This comment was originally posted on Reddit
September 23rd, 2009 at 5:12 pm
I can do reloads after signature changes until I’m blue in the face with Jetty and OSGi. The problem here is the pathological piece of junk called Tomcat. Well, that and hierarchical classloaders.
This comment was originally posted on Reddit
September 23rd, 2009 at 5:45 pm
Factor in reddit et al and I reckon it’s closer to 15-20 weeks per year
This comment was originally posted on Reddit
September 23rd, 2009 at 6:24 pm
The Java EE Container Redeploy & Restart Report:http://www.zeroturnaround.com/blog/java-ee-container-redeploy-restart-turnaround-report/
This comment was originally posted on Twitter
September 23rd, 2009 at 6:37 pm
@sbrown123 Explain in more detail then because I took a quick look at the source of Tomcat: See the reload(), start(), stop() methods at http://www.docjar.com/html/api/org/apache/catalina/core/StandardContext.java.html And the invocation at http://www.docjar.com/html/api/org/apache/catalina/loader/WebappLoader.java.html backgroundProcess() JVM only option is the dropping and creating a new classloader. There is no other way.
This comment was originally posted on Reddit
September 23rd, 2009 at 6:56 pm
JRebel does this. Think of JRebel like the JVM hot-swap the way it was meant to be. It does method addition/removal, field addition/removal, modifier munging, etc. About the only thing you *can’t* do with it is mess around with the inheritance hierarchy (I understand this is coming in version 3.0). Oh, and it’s faster than JVM hot-swap too. As for the internals, I really don’t know all that much. However, I do know that it’s not doing anything with the ClassLoader (you’re thinking of Tapestry). You start the JVM passing the -javaagent switch and specifying the JRebel jar. Thus, JRebel is actually operating at a lower level than the ClassLoader. It does have its limits. If you change tons and tons of code, particularly code which manages state, then you might get things into an unworkable form. That doesn’t happen too often though. Most of the time, JRebel works exactly as advertised.
This comment was originally posted on Reddit
September 23rd, 2009 at 7:24 pm
Tomcat uses 1 classloader per web application. They have a series of these in a parent-child relationship (see documentation on their site). The one for web applications is different than the standard classloader ([see](http://www.docjar.com/docs/api/org/apache/catalina/loader/WebappClassLoader.html)). What does this mean: 1. Tomcat does not need to be restarted. 2. Only the one web application classloader is effected by the change. All other web applications stay as is. 3. There is no deployment. Deployment means that files are sent somewhere, which under proper configuration is not required. 4. This reload can occur without effecting the current session information. This is because Tomcat normally caches the information. This is a huge time savings if you are loading up lots of information in to memory.
This comment was originally posted on Reddit
September 23rd, 2009 at 9:01 pm
[Twitter*feed] Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaro.. http://bit.ly/4gUoo
This comment was originally posted on Twitter
September 23rd, 2009 at 9:57 pm
Call it what you like, the app must be reinitialized. In most cases this takes a bunch of time. It’s possible to drive that time down for some application, but not for all.
This comment was originally posted on Reddit
September 23rd, 2009 at 11:02 pm
Usually just running in debug mode will give you class hotswapping and jsp refresh
This comment was originally posted on Reddit
September 23rd, 2009 at 11:20 pm
if it’s good why would the state of open/closed source by an issue?
This comment was originally posted on Reddit
September 24th, 2009 at 12:27 am
devs waste 3-7 weeks is slow redeployments…wonder if they should b redelploying that frequently in the 1st place http://tinyurl.com/lpxj6o
This comment was originally posted on Twitter
September 24th, 2009 at 12:46 am
Java EE container reboot survey results – http://bit.ly/114tmh
This comment was originally posted on Twitter
September 24th, 2009 at 4:23 am
I don’t work there anymore, but I’ll keep that in mind the next time I need to work with Java. Thanks, and have an upvote.
This comment was originally posted on Reddit
September 24th, 2009 at 6:01 am
combien de temps passez-vous à redéployer vos applications JEE ?
http://tiny.cc/6UWK2
This comment was originally posted on Twitter
September 24th, 2009 at 8:49 am
I really can confirm that IBM WebSphere leads to less productive developers: http://bit.ly/1clgDN
This comment was originally posted on Twitter
September 24th, 2009 at 10:21 am
http://bit.ly/114tmh
This comment was originally posted on Twitter
September 24th, 2009 at 11:15 am
http://imgs.xkcd.com/comics/compiling.png
This comment was originally posted on Reddit
September 24th, 2009 at 12:34 pm
Yes, you’re right. There must be something very wrong with the way the software is installed here.
This comment was originally posted on Reddit
September 24th, 2009 at 1:19 pm
Better you than me :)
This comment was originally posted on Reddit
September 24th, 2009 at 1:54 pm
Java container survey on redeployment and restarting. It’s interesting, read it – http://bit.ly/OVuA
This comment was originally posted on Twitter
September 24th, 2009 at 2:03 pm
Java developers spend about 3-7weeks deploying! According to Zeroturnaround (JRebel) http://bit.ly/vrP6j
This comment was originally posted on Twitter
September 24th, 2009 at 2:16 pm
Some JEE developers spent 3 to 7 work weeks per year exclusively on the redeploy phase: http://bit.ly/4xcVx I don’t, I use @playframework :)
This comment was originally posted on Twitter
September 24th, 2009 at 2:37 pm
o/ RT @gimenete Some JEE devs spent 3 to 7 work weeks per year on the redeploy phase: http://bit.ly/4xcVx I don’t, I use @playframework :)
This comment was originally posted on Twitter
September 24th, 2009 at 2:50 pm
The Java EE Container Redeploy & Restart Report – measuring Turnaround Time http://is.gd/3DjlR
This comment was originally posted on Twitter
September 24th, 2009 at 3:41 pm
interesting avg deploy time on JEE App Servers by developers http://bit.ly/vrP6j
This comment was originally posted on Twitter
September 24th, 2009 at 4:23 pm
Zeroturnaorund survey – http://is.gd/3DpKV – WebSphere has only12% marketshare. Very different from the official line.
This comment was originally posted on Twitter
September 24th, 2009 at 5:22 pm
Yo confirmo a los contenedores JEE más lentos: http://twurl.nl/5vr0em
This comment was originally posted on Twitter
September 24th, 2009 at 9:15 pm
Classloader leaks are a constant problem for any container. Eventually you run out of permgen space. There is no fix except to shutdown and restart.
This comment was originally posted on Reddit
September 25th, 2009 at 1:14 pm
Java EE Container Redeploy & Restart Report: http://bit.ly/vrP6j. Java devs are the most patient people in the world.
This comment was originally posted on Twitter
September 25th, 2009 at 4:55 pm
@cschalm: I really can confirm that IBM WebSphere leads to less productive developers: http://bit.ly/1clgDN (via @lbois)
This comment was originally posted on Twitter
September 26th, 2009 at 7:23 am
Assuming the developers are doing their own building/deploying on their own machine and staring at the screen twiddling their thumbs while it happens, yes. I would probably call that "doing it wrong" though.
This comment was originally posted on Reddit
September 26th, 2009 at 7:24 am
oh, shut the hell up, europe…:)
This comment was originally posted on Reddit
September 26th, 2009 at 7:25 am
More like use a build server for doing your builds and deployments.
This comment was originally posted on Reddit
September 26th, 2009 at 7:29 am
It takes me about 30 seconds with a really large project, but then I’m using a build server and msbuild/nant to build/deploy on checkin to the main branch. Build server is a 64-bit quad 2.something with 4 gigs of RAM. Software involved in source control, automating builds, and notification is all free and takes about an hour to set up (and an additional 15 minutes per project.)
This comment was originally posted on Reddit
September 26th, 2009 at 4:32 pm
I’m pretty convinced it’s not the compile time, it’s the "IIS flushing the app pool" that takes so long.
This comment was originally posted on Reddit
September 28th, 2009 at 7:12 am
Некоторые JEE разработчики тратят от 3 до 7 недель в году на redeploy фазу (http://bit.ly/4xcVx). Я не трачу: http://playframework.org/
This comment was originally posted on Twitter
September 28th, 2009 at 7:58 pm
Rod Petrović (imag): Java EE Container Redeploy & Restart Report: http://bit.ly/vrP6j. Java devs are the most… http://ff.im/8ScNZ
This comment was originally posted on Twitter
September 29th, 2009 at 3:17 am
Interesting article about productivity loss due to JavaEE Container restarts. http://bit.ly/1clgDN
This comment was originally posted on Twitter
October 1st, 2009 at 8:23 am
Java Servlet Container Redeploy/Restart times: http://bit.ly/114tmh
This comment was originally posted on Twitter
October 5th, 2009 at 6:13 am
How long does it take to restart your container and redeploy your app? : http://bit.ly/Gmkzk
This comment was originally posted on Twitter