Java

O Application Servers, Where Art Thou?

With Java EE 6 and GlassFish v3 out, it is time to take a little break and look at the application server world. J2EE 1.2 was created in 1999, that’s 10 years ago. The application server market at the time was completely different of the one today. There was Weblogic and Websphere, other proprietary application servers (not following J2EE) and no open source application server. Today, it is a completely different story.

The application servers’ world has changed so much in the last 10 years, but people still have in mind the heavyweight server that takes huge amount of RAM, disk space and takes ages to start (being completely useless for agile developers who need to test and code quickly and often). So let’s focus on some application servers  (Geronimo, GlassFish, JBoss, Jetty, JOnAS, Resin, Tomcat, Weblogic and Webspere) and check some parameters.

The benchmark

Disclaimer :This is not a real benchmark !

In this little test I’m just concerned about the usability of an application server for a developer. The idea is to download it, install it, start it and take some measurements (size of download, ease of installation, size of disk, startup time, size of RAM…). That’s all. No deployment of an application, no fancy twists to gain performance…. Because some of these application servers are resource consuming, I’m doing all my tests on a Windows XP virtual machine (running on Virtual Box 3.1). It is a fresh install of Windows XP sp3 with 1Gb of RAM and not too many software installed (I had to install Avast but). So when I boot there are 27 processes running and using 230 Mb of RAM (leaving 770 Mb free). Virtualizing can be slower, so keep in mind that startup time can be a bit faster that what I’m giving you here. I use JDK 1.6.0_17 (when it’s not bundled with the server). No optimization at all is made (I haven’t twisted the JVM, or antyhing application server parameter, everything comes out of the box).

To calculate the startup time, I don’t do any fancy rocket science either. I just start the server a few times, check how long it takes and use the best startup time. Also remember that some servers do not load any container at startup, making them very fast to start. Others load everything (making them slower). Again, I have to point out that I’m not deploying an application, so it’s really starting up the server from a fresh install. To calculate the memory footprint, I just use the Windows task manager and check the size of the java.exe process.

Disclaimer bis : Some of these servers were completely unknown for me, so I might not have been completely accurate. Feel free to leave a comment.

Disclaimer Ter : And again, this is not a real benchmark, so don’t use it to sale any product to your customer ;o) I just wanted to give an overview of most application servers and some numbers.

Geronimo

Geronimo is the Apache Java EE 5 application server.

Geronimo 2.x

Geronimo 2.x comes with two flavours : one bundle with Jetty, the other one with Tomcat (the one I’ve picked up).

Version 2.1.4
What do you get ? Java EE 5
Who is behind? Apache
Open source? ASL
Documentation Documentation
Download Zip file
Size of the downloaded file 73.5 Mb
Installation mode Unzip
Size once installed on drive 101 Mb
How to start it Execute %GERONIMO_HOME%\bin\geronimo start
Location of log files %GERONIMO_HOME%\var\logs
Best startup time 17.6 s
Size of the process in RAM at startup 118.8 Mb
Welcome page http://localhost:8080/
Admin console http://localhost:8080/console/portal/Welcome (*)

(*) user : system / pwd : manager

GlassFish

GlassFish is the open source reference implementation of the last Java EE specifications.

GlassFish 2.x

GlassFish v2 is the reference implementation of Java EE 5.

Version 2.1.1-b31g
What do you get ? Java EE 5
Who is behind? Sun
Open source? Dual license CDDL and GPL
Documentation Documentation
Download Jar file
Size of the downloaded file 62.9 Mb
Installation mode First java -Xmx256m -jar filename.jar and then ant -f setup.xml
Size once installed on drive 128 Mb
How to start it Execute %GLASSFISH_HOME%\bin\asadmin start-domain
Location of log files %GLASSFISH_HOME%\domains\domain1\logs
Best startup time 12 s
Size of the process in RAM at startup 96.3 Mb
Welcome page http://localhost:8080/
Admin console http://localhost:4848

GlassFish 3.x

GlassFish v3 is the reference implementation of Java EE 6.

Version 3.0
What do you get ? Java EE 6
Who is behind? Sun
Open source? Dual license CDDL and GPL
Documentation Documentation
Download Zipfile
Size of the downloaded file 73.6 Mb
Installation mode Unzip
Size once installed on drive 90.4 Mb
How to start it Execute %GLASSFISH_HOME%\bin\asadmin start-domain
Location of log files %GLASSFISH_HOME%\domains\domain1\logs
Best startup time 5.6 s
Size of the process in RAM at startup 76.2 Mb
Welcome page http://localhost:8080/
Admin console http://localhost:4848

JBoss

JBoss is the RedHat open source application server.

JBoss 5.x

JBoss 5 is a Java EE 5 application server

Version 5.1.0-GA-jdk6
What do you get ? Java EE 5
Who is behind? JBoss/RedHat
Open source?
Documentation Documentation
Download Zip file
Size of the downloaded file 127 Mb
Installation mode Unzip
Size once installed on drive 151 Mb
How to start it Execute %JBOSS_HOME%\bin\run (*)
Location of log files %JBOSS_HOME%\server\default\log
Best startup time 1m 17 s
Size of the process in RAM at startup 242.7 Mb
Welcome page http://localhost:8080/
JMX console http://localhost:8080/jmx-console/

(*) That’s using the default domain

JBoss 6.x

JBoss is still a work in progress. It will eventually implement Java EE 6.

Version 6.0.0-M1
What do you get ? Java EE 6
Who is behind? JBoss/RedHat
Open source? Dual license CDDL and GPL
Documentation Documentation
Download Zipfile
Size of the downloaded file 154 Mb
Installation mode Unzip
Size once installed on drive 180 Mb
How to start it Execute %JBOSS_HOME%\bin\run
Location of log files %JBOSS_HOME%\server\default\log
Best startup time 59.7 s
Size of the process in RAM at startup 225.2 Mb
Welcome page http://localhost:8080/
JMX console http://localhost:8080/jmx-console/

Jetty

Jetty provides an HTTP server, HTTP client, and a Servlet container.

Jetty 6.x

Version 6.1.22
What do you get ? Servlet 2.5
Who is behind? Intalio
Open source? Yes with Apache License 2.0 (*)
Documentation Jetty Documentation
Download Zip file
Size of the downloaded file 24.3 Mb
Installation mode Unzip the file
Size once installed on drive 69.3 Mb
How to start it Execute %JETTY_HOME%\java -jar start.jar
Location of log files %JETTY_HOME%\logs
Best startup time 7.1 s
Size of the process in RAM at startup 26.8 Mb
Welcome page http://localhost:8080/
Snoop page http://localhost:8080/test

Jetty 7.x

Version 7.0.1
What do you get ? A servlet 3.0 container
Who is behind? Intalio
Open source? Dual licensing
Documentation Jetty Wiki
Download Zip file
Size of the downloaded file 2.2 Mb
Installation mode Unzip the file
Size once installed on drive 2.8 Mb
How to start it Execute %JETTY_HOME%\java -jar start.jar
Location of log files %JETTY_HOME%\logs
Best startup time 1240 ms
Size of the process in RAM at startup 26.9 Mb
Welcome page http://localhost:8080/

JOnAS

JOnAS is an application server part of the OW2 development community.

JOnAS 5.1.1

Version 5.1.1
What do you get ? Java EE 5
Who is behind? OW2
Open source? LGPL
Documentation JOnAS Documentation
Download Zip file
Size of the downloaded file 134 Mb
Installation mode Unzip the file
Size once installed on drive 148 Mb
How to start it Execute %JONAS_HOME%\bin\jonas start
Location of log files %JONAS_HOME%\logs
Best startup time 15.3 s
Size of the process in RAM at startup 73.6 Mb
Welcome page http://localhost:9000/
Admin page http://localhost:9000/jonasAdmin

Resin

Resin provides an HTTP server, HTTP client, and a javax.servlet 2.5 container.

Resin 3.x

Version 3.1.9
What do you get ? Servlet 2.5
Who is behind? Caucho
Open source? Yes with GPL License
Documentation Documentation Index
Download Zip core
Size of the downloaded file 9.9 Mb
Installation mode Unzip the file
Size once installed on drive 26.6 Mb
How to start it Execute %RESIN_HOME%\httpd.exe
Location of log files %RESIN_HOME%\logs
Best startup time 1752 ms
Size of the process in RAM at startup There are 3 processes : httpd (2.8 Mb), a console to start/stop (48Mb), a process (24.3Mb)
Welcome page http://localhost:8080/
Admin console http://localhost:8080/resin-admin/

Resin 4.x

Resim 4.x is still in development. It implements the Java EE 6 Web Profile.

Version 4.0.2
What do you get ? Java EE 6 Web Profile
Who is behind? Caucho
Open source? Yes with GPL License
Documentation Documentation Index
Download Zip core
Size of the downloaded file 16.9 Mb
Installation mode Unzip the file
Size once installed on drive 28.2 Mb
How to start it Execute %RESIN_HOME%\resin.exe console
Location of log files %RESIN_HOME%\logs
Best startup time 1640 ms
Size of the process in RAM at startup 49 Mb
Welcome page http://localhost:8080/
Admin console http://localhost:8080/resin-admin/

Tomcat

Apache Tomcat is an open source software implementation of the Servlet specification. So we can say it’s a web container that servers Servlets and JSPs.

Tomcat 6.x

Version 6.0.20
What do you get ? Servlet 2.5
Who is behind? Apache
Open source? Yes with Apache Software License
Documentation Documentation Index
Download Zip core
Size of the downloaded file 6.1 Mb
Installation mode Unzip the file
Size once installed on drive 9.8 Mb
How to start it Execute %TOMCAT_HOME%\bin\startup.bat
Location of log files %TOMCAT_HOME%\logs
Best startup time 591 ms
Size of the process in RAM at startup 23.3 Mb
Welcome page http://localhost:8080/
Admin console (*) http://localhost:8080/manager/html

(*) To be able to log on to the admin console, you need to change the %TOMCAT_HOME%\conf\tomcat-users.xml configuration files and add a manager role.

Weblogic

Oracle Weblogic server belonged once to BEA and is a Java EE 5 application server.

Weblogic 10.x

Version 11g Rel 1 (10.3.2)
What do you get ? Java EE 5
Who is behind? Oracle
Open source? No, commercial product
Documentation Weblogic Server Documentation
Download Installer
Size of the downloaded file The installer is only 42 Mb. But the total downloaded is 738 Mb
Installation mode Run the installer wizard with the Typical install type
Size once installed on drive 1.2 Gb
How to start it You need to create a domain with the wizard.
Then run %WEBLOGIC_HOME%\user_projects\domains\base_domain\bin\startWebLogic.cmd
JDK bundled 1.6.0_14
Location of log files %WEBLOGIC_HOME%\user_projects\domains\base_domain\servers\AdminServer\logs
Best startup time 9 s
Size of the process in RAM at startup 126.2 Mb
Admin console http://localhost:7001/console

Websphere

Websphere 7.x

Websphere 7 is the Java EE 5 application server of IBM.

Version 7
What do you get ? Java EE 5
Who is behind? IBM
Open source? No, commercial product
Documentation Documentation
Download Zip file
Size of the downloaded file 838 Mb
Installation mode Unzip + Wizard install (with all the defaults)
Size once installed on drive 1.16 Gb
How to start it Execute %WEBSPHERE_HOME%\AppServer\profiles\AppSrv01\bin\startServer.bat server1 -profileName AppSrv01
Location of log files %WEBSPHERE_HOME%\AppServer\profiles\AppSrv01\logs\server1
Best startup time 47.2 s
Size of the process in RAM at startup 133 Mb
Admin console https://localhost:9043/ibm/console

Conclusion

There is not a real conclusion that you can take out of these tests, just some hints and numbers to show you that things are moving. Comparing Websphere with Tomcat is like comparing apples with bananas. Of course Tomcat is way faster and lighter than Websphere, but it doesn’t do the same thing. Also some application servers are minimalist and only come with application containers. On the other hand, other come with integrated portals and so on. So, of course, the startup time is different.

All that to say that the figures of the table below have to be taken with respect of what the application server does (remember that Tomcat and Jetty are just servlet containers). In red the less efficient, in orange the second less efficient, in green the most efficient, in blue the second most efficient.

App server What you get Size on drive Startup time Process size
Geronimo 2.x Java EE 5 101 Mb 17.6 s 118.8 Mb
GlassFish 2.x Java EE 5 128 Mb 12 s 96.3 Mb
GlassFish 3.x Java EE 6 90.4 Mb 5.6 s 76.2 Mb
JBoss 5.x Java EE 5 151 Mb 1m 17 s 242.7 Mb
JBoss 6.x Java EE 6 180 Mb 59.7 s 225.2 Mb
Jetty 6.x Servlet 2.5 69.3 Mb 7.1 s 26.8 Mb
Jetty 7.x Servlet 3.0 2.8 Mb 1240 ms 26.9 Mb
JOnAS 5.x Java EE 5 148 Mb 15.3 s 73.6 Mb
Resin 3.x Servlet 2.5 26.6 Mb 1752 ms 75.1 Mb
Resin 4.x Java EE 6 Web Profile 28.2 Mb 1640 ms 49 Mb
Tomcat 6.x Servlet 2.5 9.8 Mb 591 ms 23.3 Mb
Weblogic 10.x Java EE 5 1.2 Gb 9 s 126.2 Mb
Websphere 7.x Java EE 5 1.16 Gb 47.2 s 133 Mb

Java EE 5

If you only concentrate on the Java EE 5 implementation, you’ll get the sub-table below :

App server Size on drive Startup time Process size
Geronimo 2.x 101 Mb 17.6 s 118.8 Mb
GlassFish 2.x 128 Mb 12 s 96.3 Mb
JBoss 5.x 151 Mb 1m 17 s 242.7 Mb
JOnAS 5.x 148 Mb 15.3 s 73.6 Mb
Weblogic 10.x 1.2 Gb 9 s 126.2 Mb
Websphere 7.x 1.16 Gb 47.2 s 133 Mb

When you read this table there are things that you would have not expected. For example, JBoss is the slowest server to startup and Weblogic is the fastest. JBoss is also the one that has the biggest memory footprint. Websphere has the second less efficient score of all categories, while GlassFish has the second most efficient scores. JOnAS, on the other hand, has the smallest memory footprint.

Again, I haven’t deployed any application, used the administration console extensively, created clusters and did any fancy performance tests. But I wanted to show you that a full Java EE 5 server can start in 9 seconds or can only take 73 Mb or RAM. With Java EE 6 coming and the Web Profile, application servers have to become more modular and carry less weight. GlassFish v3 is a good example as it starts up in only 5.6 seconds and Resin 4 in 1640 ms. Application servers today are not the same that when they were created 10 years ago. Things have changed : Java EE 6 has become lighter, and so are the application servers.

PS : If I have omitted an application server that you (and I) think is important, let me know and I’ll give it a try and add it to the list. If you have any information to report, feel free to leave a comment.

37 thoughts on “O Application Servers, Where Art Thou?”

  1. I’d expect using the GlassFish v3 web profile would improve yet a bit more the scores.

    Reply

  2. Thank you so much for these figures !

    I have always heard that Jetty was the Good and WebSphere the Ugly.

    According to your figures, Tomcat has the fastest startup time and WebSphere is never the less efficient.

    Rumors 🙂

    Cyrille

    Reply

    1. It’s not a rumor, WebSphere sucks very hard as we all know. Finding something worse in various areas doesn’t justify anything and doesn’t make it a good citizen.

      Reply

  3. Thanks for the research.

    I would be curious to know if the measurements remain alike when you deploy a simple test application (servlet or JEE, respectively) that uses some basic features (state full session bean, JMS, JPA). I think deploying an application would reveal more interesting details.

    Bien à toi 🙂
    Tasha

    Reply

    1. This is one of my plans (but for 2010 ;o) I’ll write an application, deploy it on each server and take some measures. Other posts will come.

      Reply

      1. 2010 may be very optimistic to test Java EE 6 features on some servers, mid 2011 may be more reasonable 🙂 .

        Sorry to be a naughty guy, shame on me !

        Cyrille

      2. Thank you Antonio for these data but I’m with Tasha here. Without deploying a business application (as opposed to the admin console), I think it’s hard to interpret anything and to conclude. Moreover, I’m not even sure startup times of “empty” app servers are comparable. Some of them have an admin console, some other don’t, some even “lazy load” it (e.g. WebLogic 10.x). So I’m very impatient to read your next posts 🙂

      3. @pascal To a degree, I think Antonio’s tests do deliver an important point. Pretty much every Java EE application server vendor talks about modularity. These tests give some insight into each vendor’s implementation (given Antonio’s admitted constraints), and how the modularity benefits the end user versus benefiting the vendor (a product’s internal architecture). I also completely agree with your point that including deployed applications is more relevant.

  4. Thank you for the time you spent on this article.

    I agree with Alexis : it would have been a little more accurate to compare on the one hand only the web profile (for JavaEE6 container) or their equivalent (tomcat, resin 3, …) and on the other hand complete JavaEE containers.

    Reply

    1. Yes, you are right. I think I’ll split the conclusion in 3 parts : servlet containers, EE 5 containers and EE 6 (+web profile) containers

      Reply

      1. Java EE 6 is backwards compatible with Java EE 5, so deploying a Java EE 5 app on GlassFish v3 and comparing to Java EE 5 appservers is a fair comparison IMHO.

  5. Well Antonio, you should be happy. At least that means you’ll be able to sell your book at every Devoxx for the next 5 years ;).

    More seriously, I’m a bit surprized about JBoss. I guess that’s because they turn on too many services by default (even though you haven’t taken the “all” profile).
    It would be interesting to add a column for the catalog prices into your table (for the commercial servers of course).

    Reply

  6. Great article!

    Which configuration of JBoss are you using? default?

    Reply

  7. Hi Antonio. Interesting post.

    How did you count startup times? For example, in the case of GlassFish v3, did you count time to get the admin console up, or just the plain server?

    Looking forward to follow-ups.

    Reply

    1. Plain server. I’ve just started it, and looked at the logs, that’s all. No admin console involved.

      Reply

      1. Thanks. If you are going for non-JavaEE containers, you may (depending on time/ambition) also look at the Grizzly-only Web Container. I need to check on the status of their Servlet container, but that might be the closest approximation to Jetty and Tomcat

  8. Antonio, the number for GF v3 startup is wrong 😉 The WebContainer is not started, hence you are comparing apple and orange…you need to deploy at least one war file to get the exact number 🙂

    A+

    — Jeanfrancois

    Reply

    1. Yes, that’s what I’ve said, I’ll be more precise. App servers come with different flavours (load everything at startup or load on demand). I’ll write another post where I’ll deploy a web app and an enterprise app and take some measures

      Reply

    2. What if the web container is not required for an app? What if it is a JRuby app? EJB batch application? Agreed that this is an apples and oranges comparison, but the fact that GlassFish doesn’t *require* a web container to start speaks to the benefits of the GlassFish v3 architecture. I agree with other threads that deploying an app would yield more relevant results. I’d also like to see a JRuby app deployed across all appservers (using the native container on GlassFish v3).

      Reply

  9. If you need a sample web-app (that has some JMeter scripts also) you can look at this:

    http://code.google.com/p/perfbench/

    You may be also interested in the code that automatically takes a heap-dump at the end of the load test.

    Thanks for your write-up ! Actually I’m thinking of measuring startup time also in “perfbench” after seeing your results.

    Reply

  10. Very interesting.

    Your comparison remind me the old time when JBoss was scaled for developers. That was at the early months of our century (2000, 2001) : WAS was taking about 4 minutes to start and JBoss only 20 seconds. Time has changed and JBoss start time is one of worst !

    I think that you should add an other info in your comparison : is the appserv starting in client or server mode ? If it starts on server mode, switching in client mode in the start script could enhance the start time.

    Reply

  12. I think that memory footprint that you give is not correct without knowing the JVM parameters as :
    -Xms
    -Xmx
    -XX:PermSize=
    -XX:MaxPermSize=
    for example for Sun JVM.
    On the other side, the startup time ( and memory footprint) depends on what you load on startup :
    autoload mecanism
    load on demand mecanism

    Reply

  13. I don’t really get it…
    What’s the interest of doing such benchmark ???
    Who cares about a 1min boot or 0.00005sec for a “server” which is at the end supposed to be running for months/…
    This answer will not be acceptable: “because the developer needs to do start/stop his app/server often when doing tests”.

    Reply

    1. The answer you rejected would be an excellent one. I don’t know exactly where, but an article was recently written (to illustrate the relevance of JRebel, actually, I think) that shows the high cost of app server restarts during dev step.

      As you noticed, these servers are “supposed to be running for month”, actually, it is a default of quality not to prepare the case they are not running as long.

      On the other hand, it must be enough to see the comments to understand this benchmarks is of interest for a lot of people.

      Reply

      1. So what ?
        You’ll chose your *production* application server because your developers can boot their server 10sec faster when running a test ? This is soooo ridiculous…

    2. You are obviously not a developer…. you have not felt the pain of wls stop / start.

      Reply

  14. Do you know Java EE is a standard. That means you’ve not to make the same choice for your dev app server and your production app server.

    And actually I insist : even for production app server IT IS ridiculous not to take the restart time in account in the choice of your production app server.

    Actually I agree it is not the main performance point, but a too long restart is definitively a blocking point.

    Reply

    1. I agree with Seb that production application servers are not chosen by companies with developer’s reboot time in mind. But, as Benoit says, I usually work with customers who have two different platforms. For example Windows & Glassfish in development, and Linux and Websphere in production. That’s a really common pattern. Then, what you have to do, is integrate really often so you come across incompatibilities issues as soon as possible.

      Reply

      1. @Antonio,

        I have seen clients where this pattern was the beginning of the end 🙂 .

        Once you have proven that a cheap Tomcat or Glassfish fits your application’s needs, someone may ask why a more expensive big Java EE server is used on production. The operations team then need strong arguments to justify the investment 🙂 .

        It’s not that big Java EE servers are useless. It’s just that if you don’t use their specific features, it may worth looking at a cheaper and simpler solution.

        Cyrille

    2. @Seb,

      I understand your point but dev teams are influencers of middleware selection and dev teams like fast restart to gain productivity.

      I have been working for more than 7 years with WebSphere, I remember we criticized the middleware because our client didn’t buy enough RAM on our desktops and WebSphere IDE (WSAD then RAD) was really slow.

      Were these critics fair for the middleware ? I don’t think so because the root problem was that the infra guy didn’t align desktops power on WebSphere IDE pre-requisite. These guys didn’t admit that choosing a big J2EE container causes big costs also on the testing and dev environments.
      At the end of the day, many dev teams had bad experience with WebSphere and influence their organization to choose another product.

      @Benoît,

      The restart duration is not very important for me as long as it is shorter than something like 5 minutes because, in a clustered architecture, node are restarted one after and the service is not interrupted.

      I currently have 3 nodes clusters on production for a high volume web site. When we deploy a new version of the application, we stop one node, replace the war, restart, test with a wget and once it is ok, go to the next node. We always have at least 2 nodes to serve the request.
      OK, it is Tomcat, the middleware start time is negligible in comparison to the application start time 😉 .

      Reply

      1. @Cyrille

        I agree with your argument for the nominal case of a critic project with HA. But if you look at departement size project, a cluster won’t be used (essentialy because of IT administration cost). Then restart time is important.

        On the other hand, on very critic HA 99,999 % projects, the cluster is not enough to ensure HA. Remember a few years ago (2003 or 2004), when 75% of all the phone numbers of the french phone operator ByTel where migrated to pass through a unique clustered big HLR.

        For a reason, that I am not aware of, one of the HLR was getting down, then all the traffic were redirected to the other node of the cluster, and the same action was realized on the second HLR, which was getting down to.

        For one day, no call phone was possible for 75% of the clients of ByTel.

        The condition are not the ones of a JavaEE project, but its the proof that clustering is not a miracle solution for critic project.

  15. @Benoît,

    I must admit that I have faced few tricky problems with domino effects when restarting cluster nodes during peak hours ; very uncomfortable situation 🙂 .

    Having a load balancer that offers to progressively add load on a restarted node is very valuable. Unfortunately, Apache mod_proxy_balancer doesn’t offer such a high level feature even if the low level features are here (primarily on the fly modification of the load factor) 🙁 .

    Cyrille

    Reply

    1. @Cyrille,

      Another use case (of a short restart time in production) : for the previous versions of the WAS Deployment manager (I don’t know for the last version), whose aim was to upgrade webapp or ear in a cluster of WAS nodes, the restart of all the nodes was launched without waiting one node was up to date.

      I even don’t speak of the re-rooting management at the load balancer and the session affinity management. If your really want a HA. You have a overhead with a great cost (In term of IT and dev.). And sometimes, for less critical applications, it may be acceptable not to manage it, but have a short restart time of the app server.

      I personnaly think that all the best practices, the technologies, and the hard have a cost and must be seen globally in a project budget, and must be presented to the client, with their ROI.

      And my opinion is still that the restart time of the app server, even in production is one of the element that must be taken in account.

      It’s is rarely the main aspect, it may be considerer as irrelevant in a project context, but it must be considered.

      Reply

      1. @Benoît,

        > Phased deployment

        On version 6.1, you need WebSphere eXtended Deployment and not WebSphere Network Deployment to do phased deployment 🙂 . I didn’t check on version 7.0 .

        It’s not an opinion on whether it is fair or not to not have phased deployment for the price of Network Deployment, these are just facts 🙂 .

        Personally, I am very happy doing phased deployment on Tomcat with a simple stupid shell script, scp, svn and curl/wget … and I keep a close look to SpringSource tcServer.

        > server startup time

        On the Spring/Hibernate web applications I deploy, focusing on the application server startup duration can be misleading because the application startup duration is much more important.

        Cyrille

  16. > “If I have omitted an application server that you (and I) think is important, let me know and I’ll give it a try and add it to the list”.

    G-WAN v3.9 is currently presented at the ORACLE Open World Expo. in San Francisco. While v3.9 is not published yet, v3.3 already support Java and could be tested here (v3.9 adds support for C#, a reverse-proxy, etc.).

    Reply

Leave a Reply