If you're like me and you have about 20 different plates of code spinning at the same time, you might find Mylar to be a valuable addition to your Eclipse environment. Basically, it allows you to arrange your work by task and it tracks what you do while you're working on that task. So what? Well, then it's able to use that information to filter a lot of the views, so things like the Package Explorer only show the you classes that are relevant to your current task. It also stores the state of the editors, so when you switch back into a task you can easily remember where you left off.

I've been using Mylar for a couple of weeks and it's changed the way I work. I really like it. Give it a try if you're a crazed multi-tasking coder.

FeedBurner is hiring in Chicago. Here's the job description:

Seeking several engineers to help us expand our offerings for publishers and advertisers. We iterate quickly, and let customers test our designs and suggest further requirements. Premium placed on thoughtful designs easily extended for future functionality. Required Skills: experience with commercial web applications. Server-side Java. Linux, Apache, MySQL. Four year degree or equivalent experience. Other: JSP, Struts, Ant, JUnit, Hibernate, Spring and RSS

In one of our recent profiling use cases, I noticed that twice as many ResultSet objects were being created than I expected, and that half of them were being created in the PreparedStatement.getWarnings() method. Turns out that we were using the Spring JdbcTemplate class (version 1.2.5) in one of our tight loops, and it calls PreparedStatement.getWarnings() after every execute, even if setIgnoreWarnings() is set to true.

Rewriting that section to not use the Spring framework gave us a 2.4% increase in throughput. Not earth-shattering, but it just goes to show that it's worthwhile to include the frameworks you depend upon in your optimization efforts.

I recently wrote that we had recently started getting more rigorous with proactive performance testing at FeedBurner, so I thought I'd share some of the tools that we're using to get the job done. If you have any suggestions for other tools that you think would be useful, please let me know!

For load generation, we're using JMeter. Yes, it's clunky, awkward, and ugly, but once you've twisted your brain around the underlying model, it's actually usable. We also considered using The Grinder, but it just didn't look compelling enough to switch to.

For pre-production use case evaluation, as well as ongoing monitoring of our production systems, we use Cacti to monitor the app servers, the db servers, and the switches. Joe even wired up the memcached servers, so we get ongoing cache performance monitoring as well. I don't know what we'd do without Cacti.

For profiling, we use JProfiler. Yes, believe it or not we'll occasionally pay for software. We hook into the Tomcat servers on our pre-production boxes and do remote profiling. Sure, I've been tempted to try out the free tools available with Eclipse TPTP, but JProfiler just does a great job so it's not worth the hassle.

Those are the three tools that have made a big difference for us. If you have some favorite tools for this kind of an app, please let me know!

I'd like to tell you about another Java book that I've found useful. Today, we have Pro Java EE5 Performance Management and Optimization by Steven Haines. It's about ... yes, Java performance: what is it, how do you measure it, how do you improve it, and how do you dig out when it shits on your head. There are a ton of resources on the web and elsewhere on this subject, but what I like about this book is that it brings some formality to the table. "Performance" is such an amorphous term, yet eminently measurable. This book helps you get your arms around the subject and suggests a very specific way to start thinking about managing performance on an ongoing basis.

At FeedBurner, the scalability and efficiency of our core app is obviously very important and has a direct bearing on our equipment purchasing plans. But, to be honest, we haven't been terribly formal about things. Sure, we run our code through a profiler on occasion, and we'll tweak our jvm settings here and there, but for better or for worse, most of our performance tuning has been reactive, usually driven by frequent db query measurement and analysis.

We've started to become a bit more rigorous, though, so the timing of this book is very fortuitous. This book covers the spectrum, from "process" all the way down to suggested JVM garbage collection settings. Chapter 10 ("Java EE Performance Assessment") is especially valuable -- it's a great overview of everything that you should be paying attention to if you have a system that needs to perform.

The writing is fairly good, although there's quite a bit of repetition, and the beginning of each chapter is a little bit Celestine Prophecy, but the author can be forgiven for trying to make things interesting. Also, Mr. Haines works at Quest Software, which produces diagnostic tools like JProbe, but his advice is almost completely tool-agnostic, which I appreciate.

So, a good book to have on hand -- you should really consider getting it if you're responsible for a web-based Java application!

You can read an excerpt here: Solving common Java EE performance problems

Kevin Burton had a nice comment in a previous post, warning against using local caches and instead suggesting using memcached. I agree. At FeedBurner, we're using memcached and we've had really good luck with it. Why memcached? Because we knew some people that used it successfully, and we've pretty much used Brad's LiveJournal growth history as a template for how we want to scale.

But as we grow, I have a few concerns, and we're soon going to be doing some research into other possible distributed cache solutions. The biggest concern is that it appears that adding or removing a memcached server causes all of the object identfiers to be rehashed, which essentially flushes the cache. We're getting to the point where we have to be a little careful as our cache warms up, so I'd prefer to be able to add and remove cache servers without having to blow the cache.

I'm certainly not ruling out staying with memcached, but I'm willing to look at alternatives. If anyone has any recommendations for things to look at, please let me know.

By Christian Bauer, Gavin King

I learned a ton from this book, especially about session management. A lot of things I learned went straight into FeedBurner, resulting in some major performance gains. I plan on re-reading this every couple of months or so, and it serves as my number one reference on Hibernate right now.

If you use Hibernate, get this book and read it cover to cover.

Continue reading "Hibernate in Action"

Hey, this could be cool: write multi-platform screensavers using Java. I think I'm going to have to check this out.

Source: SaverBeans Screensaver SDK Readme

Pleasant surprise today ... Jason released a new version of JDOM, my Java XML library of choice. New version is Beta 10 RC1, which is expected to be the last Beta before the 1.0 release.

Source: JDOM: News

Continue reading "New Version of JDOM"

Implementing a persistent login cookie is one of those annoying little tasks that you have to do when creating a web UI. I just wanted to say thank you to Charles Miller for documenting his best practice for handling that ... good job.

Source: The Fishbowl: Persistent Login Cookie Best Practice

One of the libraries that we've been using pretty extensively (see earlier post "Back to the Basics with Java") is Spring, and they just released a new milestone (M4). Upgrading required some minor rework in our app, but all the changes that were made in the framework were totally rational, so I didn't mind. All the JUnit tests pass for our app, so we're going to run with it for a while.

I stumbled on this release by visiting the home page, but I now see that this is a SourceForge project, and one of the (many) great things about being a SF project is they provide RSS feeds for project releases (example: Spring Framework Release RSS Feed). So that got me thinking to what we were talking about the other day about splicing feeds. It would be useful to have a spliced feed for all of the libraries that we employ in our app. If only Jakarta had feeds for their releases!

We've been hard at work here at the Burning Door compound banging out a big ole' scalable Java web application, and it's fun to see how the platform has evolved over the years. When we first created spyonit.com, J2EE didn't even have an acronym yet, so Enterprise JavaBeans didn't even exist yet. So what did we do? What most everyone did back then: we rolled our own persistence layer, our own RMI-based distributed fault-tolerant component architecture, and all sorts of other plumbing that didn't really have anything to do with the "business logic" of the application.

Guess what? It worked. It was a big pain to have to maintain all of the infrastructure code as well as the app code, but since we had built it, it was transparent and we could go ahead and fix what needed fixing. Would I do it the same way today? No f'ing way.

In fact, when we were acquired, we embarked on an effort to refactor the application using EJBs, JMS, and all that J2EE goodness so we could deploy on top of a "real" web application server like WebLogic. Then we wouldn't have to worry about all that infrastructure code and get all sorts of magical benefits like "linear scaling" and "distributed transaction management".

I learned a few things during that effort. First, there's no real "halfway" when you start down the EJB road: it's best just to bite the bullet (to mix metaphors) and refactor things to the "EJB" way even if it doesn't really map to the system architecture as it existed before. Second, when treated as a whole, the J2EE spec really is an impressive bit of engineering design, and it's nice to be able to stand on the shoulders of people that think about that stuff all the time. Third, if something ever went wrong when you actually deployed your app, good luck trying to find which of the 29 configuration files you messed up on, assuming you haven't stumbled upon some undocumented limitation of the app server itself. It really makes for an overall slow, "unagile" development process and some miserable debugging.

Which brings us to an article I read a little while ago entitled "Simpler Java". Fully buying into EJBs is just so heavy and ponderous that there's a bit of a backlash which results in some intriguing options. There are so many amazing open source frameworks and libraries available today, you can save yourself an incredible amount of time and effort by surveying what's out there. That's what we're doing here. I just wanted to share with you what my classpath currently looks like and my thoughts on the various packages we're leveraging here at BD.

Continue reading "Back to the Basics with Java"