I have been working on stress testing a Java web application (JSP+Tomcat6+Struts2+Hibernate+mysql) and well the results I was getting wasn't something to brag about! So I upgraded the tomcat version to 7, and wow! the requests/sec I got was 5 times better than before.
So enlighten me, is there this much difference between tomcat6 and tomcat7's performance? or there is something wrong with my configuration and stuff?
The Tomcat "Which Version" page includes a high level overview of the differences between different Tomcat versions. The section for Tomcat 7.x does not claim massive performance increases for Tomcat 7.x versus Tomcat 6.x. A Google search didn't offer any clear evidence either.
I'd be inclined to think that a 5-fold throughput improvement is either:
a Java / Tomcat configuration and/or tuning issue,
something a bit unusual about your web application, or
an unidentified artefact of the way you are doing your performance measurements.
What is the difference between Tomcat 7.0 and Tomcat 6.0?
Tomcat 7.0 has improved the security over Tomcat 6.0 due to several security code fixes and additions (such as CSRF prevention filter).
Tomcat 7.0 includes Servlet 3.0 API, which it self is an improved version over its previous version (used by Tomcat 6.0).
So, 3rd party applications that need Servlet 3 containers are supported by Tomcat 7.0.
Configurability is better in Tomcat 7.0, which includes new container components (e.g. ExpiresFilter and AddDefaultCharsetFilter) that allow better handling of problems previously left to the web applications to resolve.
Tomcat 7.0 supports Java 6 or further version, while Tomcat 6.0 supports Java 5 or further version.
Finally, Tomcat 7.0 includes cleaner and modernized code that uses generics in the required places.
Related
This question already has answers here:
What is the difference between Tomcat, JBoss and Glassfish?
(8 answers)
Closed 8 years ago.
I would like to start using JEE6 in the next project that I have to work on at my job, but there is also a limitation (sort of): Tomcat 5.5
My question is, what improvements would bring GlassFish to the table (security/speed) vs the existing Tomcat(5.5) or an upgrade to the newer version 7?
Q: My question is, what improvements would bring GlassFish to the table
(security/speed) vs the existing Tomcat(5.5) or an upgrade to the
newer version 7?
Tomcat 7 compared to Tomcat 5.5 supports newer version of JSR specifications. Therefore, if you wish to use for example Servlet 3.0 or Websockets, you don't have other choice but to upgrade the Tomcat version. See this link for the full list of Tomcat versions and supported specifications.
However, Tomcat is not Java EE container, but only a servlet container. In other words, if you plan to use full Java EE (which includes security and many other things), you have to switch from Tomcat to some of full Java EE application servers. Glassfish is one of them, others are TomEE (similar to Tomcat, so perhaps a good starting point), WildFly, IBM Websphere, Oracle Weblogic etc. Unfortunately, Oracle recently decided to abandon commercial support for Glassfish, so maybe it would be wise choice to go with some other application server if you would like to use it commercially.
One way or another, move from Tomcat 5.5 because it is a quite old version of Tomcat.
See also:
Java EE containers vs Web containers
Oracle abandons commercial support for Glassfish JEE Server
I am using Jboss 2.4.11, if i upgrade JDK from 1.4 to 6 How is the jboss server going to handle the application?. What are the common things i should start investigating while i am in the process of the upgrade. I am looking at the Oracle's documentation and other posts in stackoverflow related to jdk 6 backwards compatibility with v1.4. My question is more specific towards using Jboss server. Also the application uses ejb 1.1
I'd recomment to move from one consistent system to another one. Even JBoss 4 needs a special version for JDK1.6. Java 5 brought MBeans rigth into the VM and older versions of JBoss used MBeans for configuration. As there must not be to MBean servers within a single VM this was a big issue, when migrated to java5. As EJB 1.1 is still supported I'd recomment to move at least to JBoss 4.2 as this is still kind of similar to older versions, while JBoss 7 is totally different.
The only thing that will really help you to get the migration a little bit smother are tests. At least quite a number of integration tests.
I just need clarifications related to JBoss Application Server. I've developed a project which is compiled in Java 6. And it is deployed in Jboss 5 version. Till now I didn't find any problem with the application. But I want to know will there be any possibility that Jboss will have any backward compatibility problem. Or does Jboss needed upgradation with respect to Java version. Any suggestion would be appreciable.
Thanks,
Marshal.
Even if JBoss 5 is compiled with Java 5 there shouldn't be compatibility problems at a language level.
As for the libraries there might be a problem but those that JBoss requires should have been taken care of. This leaves you with core libraries that JBoss might have replaced in its class loader hiearchy and thus might have an older version. In that case you could put those libraries into your application and effectively override the JBoss versions on a per-application basis. We did that with some XML libs (IIRC JAXB was one of them).
As an alternative - as suggested by #Geziefer - use a JBoss 5 version specifically compiled for Java 6.
Can anyone tell me if it is currently possible to "glue together" a partial Java EE 6 Web Profile over Jetty?
I've found a lot of articles about integrating standalone EJB 3 containers, JTA providers, etc with older Jetty versions, so I wounder if I could make it all work together.
I would like to assemble a Servlet 3.0 + CDI + EJB 3.1 + JTA (if needed, all I really want is declarative transaction management) + JPA 2 environment over Jetty 8 (or Tomcat 7 if no Jetty alternatives are available).
My questions are: Can it be done? Has anyone managed to do that? Any articles about getting OpenEJB, Atomikos, Weld, EclipseLink and Jetty (or any other similar stack) working together? Any magical "do it all" pom.xml files out there?
PS: Yeah, I know I could just use GlassFish (which I like very much). I'm just wondering about how hard would it be to get something similar working with a Servlet Container, and how the two environments would compare in terms of complexity, performance, size, deploying speed, hardware resource consumption, etc.
I'd describe this as still in the early stages, but here is what we have so far:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/openejb-jetty/
Note, Apache TomEE lives at a similar path, i.e. 'assembly/openejb-tomcat'. Plan is to call the Jetty version Apache JetSet and have it be fully embeddable. Most people with commit are currently working on getting Apache TomEE to be officially Java EE 6 Web Profile certified. I'd describe that work to be in the late stages. We've a great setup in Amazon EC2 to run the web profile TCK against TomEE using a hundred EC2 t1.micro spot instances. It's pretty sweet. The TCK agreement with Apache and Oracle does not allow us to share access publicly. However, any Apache committer can sign an NDA to get access.
Ok, so I mention all that about TomEE because the plan is once we're done with the Tomcat version, to do it all over again with Jetty (JetSet). Many of us committers, myself and Jonathan Gallimore for example, actually prefer Jetty by a large margin. But as the Tomcat integration code was much further along and had more users, we decided to just finish that one first. There is an incredible amount of work that isn't Tomcat specific that we will be able to leverage in the Jetty version; getting access to the TCK legally, the heaps of code to get it to run, the more heaps of code to get it automated, and numerous integration bits which are generic and not specific to Tomcat.
All that said, there's no reason others have to wait to work on a Jetty version just because most of us are still finishing the Tomcat version. Apache projects should be viewed as individuals working together, not companies like Oracle or Redhat or VMWare. That can be both good and bad. The good part is that if you or anyone else wants to hack on the Jetty version you can do that right now. You'll have to submit patches for awhile till you earn commit, but having someone else do the actual commit command is not that bad. If you start small and stay active and open, it's usually pretty easy to earn commit. The key to getting patches in quickly is a steady stream of small to moderately sized patches. Any step forward or sideways with no steps backward is a good patch in my opinion. As long as people can see where you're going it's good enough. Certainly more Agile than the one-big-patch approach and allows for all the really fun and collaborative magic to happen along the way.
Some threads which would be good places to say hello. Step 1 is just to say hello. No need to have code in hand to talk on the dev list or be taken seriously:
http://openejb.979440.n4.nabble.com/Jetty-Integration-td1457408.html
http://openejb.979440.n4.nabble.com/Jetty-Integration-td2318962.html
Tomcat has that stack implemented in a server called TomEE(formerly TomTom).
These are the components it uses.
Connector Apache Geronimo Connector
CDI Apache OpenWebBeans
EJB Apache OpenEJB
Javamail Apache Geronimo JavaMail
JPA Apache OpenJPA
JSF Apache MyFaces
JSP Apache Tomcat
JSTL Apache Tomcat
JTA Apache Geronimo Transaction
Servlet Apache Tomcat
As far as Jetty I'm not sure. OpenEJB is your only option for EJB outside of a JavaEE6 container(AFAIK) and I'm not sure Jetty is 100% tested with this. For CDI you can always use something like Seam.
In my opinion I believe the Spring framework would be your best option for the Jetty container(that's just my opinion though). In my experience after trying to get Tomcat working with Open EJB, Spring is a lot easier to set up.
You also have to remember Open EJB doesn't implement the entire EJB 3.1 stack at this point.
Also Open EJB is not tested on Tomcat 7 either. So you have to stay with Tomcat 6 if you go that route.
OpenEjb has not released a version with JPA2 support, although their development version supports JPA2 fine AFAIK.
I'm using embedded OpenEjb in Jetty6, because I could not get my app working in newer jetties yet. I think there is work under way to get an OpenEJB tightly integrated with Jetty like TomEE, but that may be some way off..
Geronimo is a complete J2EE stack which runs on top of Jetty.
There's a document on its setup on https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-jetty.html
What is the best Java EE server to deploy coldfusion 9 on? I know there is Tomcat but i'm sure there are others.
The ColdFusion support matrix lists a limited number of Java EE servers that they support:
WebLogic Server 9.2, 10.3
WebSphere Application Server ND 6.1, ND 7
JRun Updater 7
JBoss 4.2, 5.01
Your choice from this list is going to be dictated by commercial realities, not technical ones - WebLogic and Websphere are the leading servers, but commercial (and expensive); JBoss is free (although you can pay for a support contract); JRun is just rubbish, and I suspect only supported because if I remember correctly, JRun and ColdFusion used to be the same platform.
Having said all that, CF may run just fine on any other appserver, but that would be unsupported.
You need to answer two or three questions to decide:
Do you know enough about it to not
want to just use JRun?
Which Java EE servers do you know well
enough to support (or know the best)?
Which of those are on the supported
servers list?
If you can deploy Cold Fusion on any Java EE app server, there are lots to choose from:
WebLogic
JBOSS
Glassfish
Jetty
WebSphere
Pick the one that fits your budget.
I've listed these in my order of preference. I think WebLogic is still the best Java EE app server out there. Let's hope Oracle doesn't kill it.
I built a ColdFusion 6.1 application for a national 401k provider deployed on JBoss and it worked very well. Actually, I was able to run CF 6 on a 64-bit JVM because I was no longer hindered by JRun.