I have a simple JSP/Servlet maven application which allows a user to upload an archive file. The application will then unzip the archive which contains XML files, and parse them using basic SAX parsing. It will generate an in-memory representation of these files, and write them to a Neo4J Graph Database, currently in embedded mode.
During development, I used a GlassFish v3 but with production in sight, the request has been made to move from Glassfish to Tomcat and so I did. Apart from a few small issues with Tomcat forcing me to add JSF dependencies despite the fact that I'm not using any JSF, there is one big issue I have with Tomcat atm.
The largest testfile I have takes about 8 seconds to upload and parse on glassfish v3. After that, it takes about 2 seconds less, due to the fact that I don't clean up the uploaded file (yet).
The same file on Tomcat7 takes about 90 seconds to upload and parse the first time. The other times it takes about 20 seconds less, presumably because of the same reason.
In any case, there's a difference in performance of factor 10. I'm a little bit surprised, since I thought that using Tomcat would actually increase the speed due to it being more lightweight than Glassfish, since I'm not really using the advanced functionalities provided by Glassfish.
Has anyone encountered a similar issue, and what did you do to resolve this? Is this even resolvable, or is it due to the way that Tomcat works...
EDIT: The difference appears to be in the code section that is responsible for writing the in-memory representation of the files to the actual database... No idea why though...
I could not find a comparison of Tomcat with Glassfish but yes, the new Glassfish versions are very light weight and have very good performance. I have experienced the same. I guess running an application server instead of a Tomcat is no more huge administration and hardware waste (and you can use light weight EJB 3 and 3.1 if you like). Glassfish installations can be very small in size if you only select the necessary modules.
Check this page. It compares Jboss, Glassfish and Resin
http://hwellmann.blogspot.com/2011/06/java-ee-6-server-comparison.html
And this one compares Glassfish 3.1 and Jboss 6 & 7.
http://hwellmann.blogspot.com/2011/10/jboss-as-7-catching-up-with-java-ee-6.html
Related
I'm trying to migrate web applications from JBoss to Spring Boot, but have some unexplained issue with VERY slow startup time.
Even simple application from Spring Boot guides - "Handling Form Submission" (packaged as a fat JAR, using Java 1.8) starts on some computers in 3 sec, but on others in 30 sec. and this is gets worse for bigger web apps (WAR-packaged with JSF, Hibernate, etc) - startup time is 13 sec vs 1500 sec (115 times more!).
Similar apps starts under JBoss or Liberty app servers starts fast everywhere.
Not sure if this is security settings, network, firewall or anti-virus tools.
Looking at the log file, it seems like application spends a lot of time on scanning JARs for TLD files and "reflection" scanning.
Strange, but this is not the issue for apps running in JBoss or Liberty - not sure if same scanning happens there.
As far as I understand, this is done per Servlet specs, but is there any way to skip scanning some JARs?
Where to add catalina.properties file in Spring Boot app, packaged as WAR, as suggested by the message?
Here are examples of log messages:
org.apache.jasper.servlet.TldScanner : No TLD files were found in [jar:file:/C:/Development/workspace-Cloud/PrimeFacesDemoSBwar/target/primefacesdemoSB.war!/WEB-INF/lib/primefaces-5.3.jar]. Consider adding the JAR to the tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in CATALINA_BASE/conf/catalina.properties file.
...
org.reflections.Reflections : Reflections took 79406 ms to scan 7 urls, producing 972 keys and 4573 values
More of a standard practice questions:
Is there any difference in deploying an app as EAR vs WAR? How do you decide? (I know WAR is just a web application may or may not have Java EE features like messaging)
Lets say I have a Spring MVC application stack with Hibernate (MySQL DB), should this be deployed as a War or EAR?
When do we need to worry about JBoss deployment descriptors, if I am not using EJBs. (Just Spring MVC). Lets assume I have JMS as well. Do we need to configure/update/create any other JBoss related config files?
When we package our application EAR/WAR, it include EVERYTHING that we need for our app. Is there a scenario where we need to keep some config / xml files outside of this archive in a specified JBoss folder?
Is it common practice to deploy directly from Eclipse or better to use Ant, etc? Advantage / Disadvantage?
Obviously, I am a newbie :-). Trying to understand this.
1.
This is not always an easy decision, but for beginners and for small projects I would say it's nearly always a WAR. The reason for using an EAR is mainly to isolate a business layer from a UI/Web layer. See this question for more details: How can one isolate logical layers of an Java EE application
2.
I might be mistaken but I think that Spring people typically prefer WARs.
3.
JBoss (vendor) specific deployment descriptors are mostly needed to configure so-called "administered objects" and security. Sometimes they can be used for extra features that are not covered by the Java EE specification (e.g. setting the web root for a WAR). Administered objects are typically data sources (connection to a database) and JMS destinations (queues and topics).
In the traditional Java EE approach these have to be created as far away from the code as possible, which typically means a system admin would create them inside the target AS using some kind of GUI or admin console. In this setup, you as developer would throw a WAR with "unresolved dependencies" over the wall, and a system admin (or "deployer") would then spend days figuring out what those unresolved dependencies should be.
If the communication is relatively good between developers and deployers, the WAR or EAR might be thrown over the wall together with a readme-file, that at least gives some insight into which resources are needed. Depending on the organization the development team might not get any access or feedback about how those "unresolved dependencies" have been resolved. E.g. a data source with a max of 5 connections may have been created, but this may be insufficient if some code does say 10 parallel queries. Without the development team knowing the exact data source configuration, some classes of runtime problems and performance issues may be relatively hard to solve.
To mitigate these problems, some vendors, for some artifacts, offer the developer to create those "unresolved dependencies" instead using proprietary deployment descriptors which are then embedded in the WAR or EAR. For simple local JMS destinations this is then in most cases the end of it, but for data sources there is a little bit more to it. Namely, there has to be a mechanism to switch between data sources for different stages such as Dev, Beta, QA, Production etc. Additionally, it's rarely a good idea to have production passwords in the source code.
If you have a simple app that you want to try out locally, stages and production passwords are not a concern. If you deploy for a (large) company it is.
In Java EE 6 you can define a data source using a standard descriptor (web.xml, ejb-jar.xml or application.xml), and in Java EE 7 you can do the same for JMS destinations. There is no standard way to configure those based on stage, but there is a glimmer of hope that Java EE 8 will address this (see e.g. JAVAEE_SPEC-19). Vendors are not universally happy with those standardized methods, and their main documentation will almost always extensibly tell you how to do those things using their proprietary tools and descriptors, and if you're lucky as a small note tell you there's a standardized way (and then sometimes downplay that or scare you by saying it's not recommended to be used in production).
4.
See answer to 3 mostly. One option to solve the problem of how to switch between stages and keep production passwords out of the WAR/EAR, is to have the full definition of said data source inside the AS (inside JBoss in your case). Every AS installation is tied to a specific server in this setup. If data sources need to be updated, removed or new ones added, you have to communicate with your operations team (if any). As said, depending on your organization this can be anything between trivial and practically impossible.
5.
When developing you most often use your IDE to do a deployment. For production you would never do that. For production you may build with Ant (or Maven) and deploy via something like Jenkins, or e.g Chef.
Check here : .war vs .ear file
If you read the preceeding response, you'd guess that "WAR" it is.
Deployment descriptor are needed to manage the modules of JBoss, if you don't have any conflict or don't need any tweaking, you won't need any deployment descriptor.
You may need to play with some JBoss file if you want to add modules to JBoss, or configure datasources, etc. Read the JBoss documentation for more info.
You can deploy from eclipse during your development phase, but as your other environments (qualification, production, test, etc) should be separeted from your developing one and that they won't have any eclipse installed on them, you should get used to manage your server from the command line and drop your war's in the right directories.
It's a short answer, but I hope it will help.
Read JBoss documentation for more info.
I have a web app running on Tomcat 6.0.35, which makes use of Spring 3.1.2, Hibernate 4.1.8 and MySQL Connector 5.1.21.
I have been trying to figure out what is causing Tomcat to keep running out of memory (Perm Gen) after a few redeploys.
Note: Don't tell me to increase Tomcat's JVM memory because that will simply postpone, the problem
Specifically, I made use of the VisualVM tool, and was able to eliminate some problems, including some mysql and google threads issues. I was also able to discover and fix a problem caused by using Velocity as a singleton in the web app, and also not closing at the correct time/place some thread local variables I was having. But I still am not completely able to eliminate/figure out this Hibernate issue.
Here is what I'm doing:
Deploy my webapp from my development IDE
Open a tomcat manager window in my browser
Start VisualVM and get the HeapDump on the tomcat instance
Go the tomcat manager and redeploy my webapp
Take another HeapDump in VisualVM
My first observation is that the WebappClassLoader for the original webapp is not garbage collected.
When I scrutinize the retained objects from the second HeapDump, the class org.hibernate.internal.SessionFactoryImpl features prominently which leads me to believe that it IS NOT being destroyed/closed by Spring or something along those lines (and hence the WebappClassLoader still having a reference to it).
Has anyone encountered this problem and identified the correct fix for it?
I don't currently have an idea what could be amiss in your setup but what I know is that using Plumbr you'll most likely find the actual leak(s).
We are developing a open source trading platform based on Springframework and Hibernate http://code.google.com/p/algo-trader/ and http://www.algotrader.ch. The application consists of a trading framework and several strategies that can be started independently. So far, these different parts have been running in separate JVM's communicating through RMI and JMS.
To avoid unnecessary serialization and network overhead we would like to run the entire application within some sort of container (potentially an application server). We do however have the requirement, that the individual parts of the application can be deployed, started and stopped independently.
We have looked into OSGi, but a lot of the libraries that we use are not OSGi ready yet, so this is not currently an option. Also please note, there is no web-GUI in our application.
Any suggestions on this?
Thanks
Andy
If OSGI is not an option then functionality can be broken into smaller units and then deploy them as utility jar, if deployed as utility jar they can be managed independently.
For application server I feel either glassfish or Jboss will be a good option considering they are open source and free.
Though at a later point in time you can check with Weblogic (Dev free).
So in your case you would like to break the static data configuration(Counterparty, Currencies), Dealing(Pricing, Quoting, Booking) as two separate feature.
For your choose of an application server i advise you Jboss and specially in his version 7.1 which is faster and more stable!
We have here an application developed using Java EE 5 stack (using JSF, RichFaces, EJB, JPA, Hibernate, JAAS) that runs inside Glassfish 3.1! The thing is we are in need to run it as an installable deploy (actually many deploys =]).
My question is: What can we do to have the smallest footprint for the system?
I've already studied about:
uninstalling thing through upgrade tool (e.g. the admin parts),
run the application using embedded glassfish (but using the already existent domain),
configuring domain.xml to erase features (but at a trial and error way),
found some work on how to configure glassfish for production environment.
But as the system will be used by one user at a time, I would like to listen from you about options in this environment.