I've been using java + spring on tomcat for the past 2 years and my app is getting notably huge. Start up time is now almost 3 minutes and it consumes a lot of resources during the development.
So I am interested in ideas how to make developing a software fun again. I've looked at Spring DM/Gemini blueprint to make it a modular but the experience was not convenient.
Now more modules are about to be added, thinking about developing it another web application and use Spring integration for messaging. Apparently, this will be a very painful experience to develop it on one desktop computer.
Has anybody any experience with cloud development? How do I improve all these time and resource consuming tasks? Will developing in the cloud help me?
It is very common problem with typical java+spring web apps. With age they start getting bloated and Context Loading starts becoming painful. I can suggest a few pointers to mitigate the issue, but only you will be able to judge best for you depending on the what exactly goes in your app.
Don't depend heavily on server while doing development. Write Unit tests and run them outside the servlet container. Spring has excellent support for this.
Split you business logic in Rest/Soap web-services (judiciously and carefully). This gives you freedom of developing and testing the UI independent of core business logic.
If using maven/gradle, try jetty plugin. It can keep scanning for changes and reloads the webapp automatically (I think tomcat plugin can do the same). It has ability to store session between restarts, so you are not affected by restarts. Please see this for more details How can I speed up Maven and Netbeans
[Paid Option] may try JRebel.
Use CI server, that keeps on integrating/testing/deploying your app, taking some load off your developers machines.
First, take care of the bottlenecks. They have a tendency to creep into projects as they grow. The original design has been compromised again and again to meet insane deadlines and now bloat has killed a once lively application.
Do not guess at the problem but use real data to determine what is making you app slow. Use a profiler such as jProfiler: http://www.ej-technologies.com/products/jprofiler/overview.html
Next, use what you've learned to make the new modules more efficient. The bottom line is changing technology is not a fix all, as all technologies can present bottlenecks. You must find the reason behind the problem and fix that.
Once you fix the bottlenecks, you could create some test projects on a new technology to see if it is faster, easier, does what you need. But, chances are just fixing the problems on your current stack is all that is needed.
Related
I've created my first Play application. Which is the most suitable deployment method for production? Should i copy the whole project to the production server and run play start? or should i make a war out of my application and deploy in tomcat / jboss? Which is the most recommended way? Getting confused with it comparing to its rails type of behavior. Note that this is supposed to be a big data application and also it may server loaded requests later on. So we are thinking of scalability, availability, performance aspects too. This application is decided to be deployed in a cloud.
Thanks.
As others have stated, using the dist command is the easiest way to deploy Play for a one-off application. However, to elaborate, I have here some other options and my experience with them:
When I have an app that I update frequently, I usually install Play on the server and perform updates through Git. Doing so, after every update, I simply run play stop (to stop the running server), sometimes I then run play clean to clear out any potentially corrupted libraries or binaries, then I run play stage to ensure all prerequisites are present and to perform compilation, and then finally play start to run the server for the updated app. It seems like a lot, but it is easy to automate via a quick bash script.
Another method is to deploy Play behind a front-end web server such as Apache, Nginx, etc. This is mostly useful if you want to perform some sort of load balancing, but not required as Play comes bundled with its own server. Docs: http://www.playframework.com/documentation/2.1.1/HTTPServer
Creating a WAR archive using the play2war plugin is another way to deploy, but I wouldn't recommend it unless you are giving it to someone who already has a major infrastructure built upon these servlet containers you mentioned (as many large companies do). Using a servlet containers adds a level of complexity that Play is supposed to remove by nature (hence the integrated server). There are no notable performance gains that I am aware of using this method over the two previously described.
Of course, there is always the play dist which creates the package for you, which you upload to your server and run play start from there. This is probably the easiest option. Docs: http://www.playframework.com/documentation/2.1.1/ProductionDist
For performance and scalability, the Netty server in Play will function very adequately to exceptional for what you require. Here's a reputable link showing Netty with the fastest performance of all frameworks and a "stock" Play app as coming in somewhere in the middle of the field, but way ahead of Rails/Django in terms of performance: http://www.techempower.com/blog/2013/04/05/frameworks-round-2/.
Don't forget, you can always change your deployment architecture down the road to run behind a front-end server as described above if you need more load balancing and such for availability. That is a trivial change with Play. I still would not recommend the WAR deployment option unless, like I said, you already have a large installed base of servlet containers in use that someone is forcing you to serve your app with.
Scalability and performance also has a lot more to do with other factors as well, such as your use of caching, the database configuration, use of concurrency (which Play is good at) and the quality of the underlying hardware or cloud platform. For instance, Instagram and Pinterest serve millions of people every day on a Python/Django stack which has mediocre performance by all popular benchmarks. They mitigate that with lots of caching and high-performing databases (which is usually the bottleneck in large applications).
At the risk of making this answer too long, I'll just add one last thing. I, too, used to fret over performance and scalability, thinking I needed the most powerful stack and configuration around to run my apps. That just isn't the case any more unless you're talking like Google or Facebook scale where every algorithm has to be finely tuned as it will be bombarded a billion times every day. Hardware (or cloud) resources are cheap but developer/sysadmin time isn't. You should consider ease of use and maintainability for deployment of your app over raw performance comparisons, even though in the case of Play the best performing deployment configuration is arguably the easiest option as well.
You don't need to use Play's console for running application, it consumes some resources and it's main goal is fast launch while development stage.
The best option is using dist command as described in the doc. Thanks to this, you don't even need to install Play on the target machine, as dist creates ready to use stand-alone application containing all required elements (also build-in server, so you don't need to deploy it with WAR in any container).
If you planning to use a cloud you should also check offers ie. from Heroku, or CloudBees, which allows you to deploy your application just by... pushing changes via git repository, which is very comfortable way, check the documentation's home, scroll down to links: Deploying to... for more details.
I would like to write an online book that shows people how to tune a Java web application by example. Using free tools, it will show people how to load test and monitor their apps so that they can make incremental performance improvements.
I already know that I want to use Jboss + Apache + Ubuntu. I don't really care whether I use MySQL or Postgresql. I also plan on using The Grinder to run my perf tests.
Now I just need to determine which Java application I want to test. Here are my high-level requirements:
FOSS - All of the tools in my book will be FOSS to lower the costs barrier.
It should be fairly secure - I may expose this application to the WWW, and I don't want to lose sleep over security.
Easy to deploy - I don't want people to spend too much time deploying the app.
Easy to load test - I would like a fairly simple UI that avoids too much Ajax.
DB-Backed - The app has to have a RDBMS backend.
Does anyone know of a good Java app that would meet these requirements?
Jenkins might be a good choice. Simple to deploy, and it might have some future benefit as well :)
I want to take the next step in java web development, I am hoping to get insight & feedback on: what my next steps should be and how best to take them.
While learning the basics of java web development, I put together a simple web app that performs simple accounting and financial calculations. The web app is on a single jvm, uses Tomcat, and has standard web functionality - i.e. login/logout, basic security, etc.
How can I make this web app more "enterprise ready" - distribute functionality of tiers over different servers/jvms, HA, balance-able, etc.
What do I need to know/learn? - i.e. EJB3 or Spring Framework (seems spring is better option), REST and/or SOAP, etc.
How would one recommend (books, websites, etc.) I learn the "requirements" (see preceding line)?
Thanks!
In my opinion, you should try different approaches for a same problem, so you could compare the pros and cons of different tools and frameworks.
For instance, try to build an application using EJB, and then the same application using Spring. Take the presentation layer of your code written with JSF and then rewrite it using Tapestry.
I think this will be very helpful to you, as you'll be able to make best decisions when choosing tools for your future developments.
A few things to consider, as food for thought:
How good is the error handling/logging of the application? For example, if the user tries to put in X in for a currency value, what does the application do?
What is configurable within the application from the user and what is in configuration files and what is in a database with regards to configuration? Do you have passwords encrypted within the application?
What patterns would used in building this application? Are there patterns you could see using now that you have a prototype?
Is this application ready to handle different currencies and languages?
What happens if someone leaves the screen for a few hours and tries to use a form?
What administrative functionality does the application have?
Does it handle the case where the user has JavaScript disabled?
What are the limitations of your application, IOW what can't it handle the way it is?
Have you considered trying to write a manual for the application?
EJB or Spring? gets asked quite a lot nowadays, here's a decent related question about them.
Have some real users using your application. You'll be amazed on how many "new" features/improvements can be performed in your app ( and the technologies you'll learn to satisfy those requirements ) by having real users using it.
I would suggest the following books/tutorials are a must for every Java developer:
Manning: Spring in Action - 2nd edition
Manning: Java Persistence with Hibernate
Core JavaServer Faces
Adobe Flex ( Adobe website video tutorials )
Effective Java
Apart from the standard technologies above you must be familiar with
Different testing frameworks , JUnit is a must
Build tools like ANT and Maven
Also you can build small projects by downloading trial versions of MyEclipse or Flex Builder.
I suggest that you create small java experiment projects for each new framework/library that you want to learn.
I've had good success using maven to help me quickly and consistently create java projects that I use to experiment with one technology at a time, such as Spring, Hibernate, etc. I use maven's site life cycle to record notes about what I learned and to document how to build and run each project. So, now I have 20 or so projects that I can use as baseline projects, one for each framework, to build upon.
Also, I prefer buying and reading books rather than relying on google and websites to learn new frameworks. Seems that I'm able to learn a lot faster this way.
I also suggest that you write web apps that you, yourself, would want to use. Or write a web app that solves a problem you've been having. I've found that I learn a lot more this way rather than simply copying and pasting from examples in a text book.
Hope that helps,
- Dave
Spring or Tapestry would be good options for new learnings. Does your app use any web services? If not work those in. Work with other application servers like JBoss and Weblogic and note their nuances with java. I'd also recommend learning Maven and work that into your build/deploy process.
Have fun,
Mike
You could vastly reduce the time taken to build your apps by learning some Test-Driven Development.
Try learning JUnit - it's becoming a core skill now, even in unagile shops.
If you're focussing on the web, try out Selenium - which has a Java controller to drive your tests from Java test cases.
After investing a bit of time in TDD will pay off no matter which frameworks or apps you work on. If you learn to test drive your code, you'll end up with smaller, cleaner code and less debugging.
You might look at AppFuse, which is a bundle of Java things together.
Or, you might take a look at a few more technologies to play with and add in:
Version Control - SVN
Tools - Ant or Maven
Framework - Spring, Seam, Struts
ORM - Hibernate or iBatis
Test Driven Development - JUnit, Emma
Continuous Integration - Hudson
I'd also read the Pragmatic Programmer and/or Code Complete.
Allow me to state that "enterprise"-ready does not necessarily imply scale-out solutions, many, many enterprise Java applications are running on larger systems requiring long-running-systems skill of their own.
I recommend mastering the Java language and runtime, understanding how bytecodes and loading traverse the JVM vs. focus on any given framework.
Speaking of frameworks and if you really have the time, try recreating an application framework yourself. Try and re-invent the wheel. IMO it is an excellent lesson in why frameworks themselves exist and teaches one to employ the features instead of always trying to work around them.
One more thing, never forget the database. I don't care what that looks like Oracle, MySQL or NoSQL, but become also an equal master at the data store.
Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?
Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.
I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.
From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.
I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.
I am having my web application deployed on Tomcat5.5 and I use it in integration with eclipse 3.2.Each time I close the eclipse and restart it, I need to republish the application even when it hasn't been modified.
Is there a way to avoid this or any step I am missing ?
Go to Preferences->Server->Launching . Remove option 'Automatically Publish When Starting Server'
I think adij.wordpress.com correctly nailed this one. If you find that you're spending a lot of time waiting for Tomcat to restart as you develop your application, consider using Jetty instead. It'll restart in a fraction of the time Tomcat does and provides a full featured alternative that is ideal for agile development.
We use Glassfish (Tomcat based) with multiple EAR files and it's dog slow for development so each EAR project contains a Jetty launcher that simply fires up for the single WAR the developer is working on at the time. If you use IntelliJ this can be made automatic so that changes at any tier of the application can be instantly reflected into the currently running application in the time it takes to click onto the browser and refresh the page.
Do eclipse 3.3 or 3.4, or later versions of WTP behave the same way for you?
As this is a quite old question and still filed under unanswered, I'd like to broaden the scope with this answer:
I assume there is a reason for you to want to cut out republishing of your application that I don't know (other than the aversion against unnecessary work being done)
The only thing I can guess is that it takes a significant amount of time. For me the publishing time has never been an issue, but if they are for you, you might think about
increasing your memory (if swapping virtual memory slows republishing) - e.g. buying new RAM
optimize dependencies in your project, e.g. prepackage dependent projects if there's a huge number of them or create subprojects and depend upon them if there's only one huge project. (This assumes, that any of these factors slows republishing. I have not measured it)
does using Tomcat6 or glassfish help?
It might be, that not publishing is your issue but startup time. You might gain a lot by controlling that very tightly, e.g. starting services on demand after the webapplication has started. I know several applications that do some heavy work during startup (before they accept their first connection and before they pass control on to the next application startup that might do the same). I hate them. Usually such services get lots of swear words and finally their own web/application server. Having to restart one of these applications should at least not make all the other applications (and their users) suffer that are written with nice startup times in mind.
If your question is still an issue and you are still looking for a solution, please comment. What is your republishing time?