 |
| | | A Developer's Perspective | |
 | Rick Ross is the founder of Javalobby. He is a frequent speaker at Java-related events and a well-known advocate for Java developer interests.. |
 Rick wakes up and smells the JMX
Have you tried out the JSR-160 JMX Remote API and the various tools like jconsole and jmap which it makes possible? I’m probably the last one in the whole Java community to have tried these tools, but I finally understand what the JCP experts envisioned when they developed JMX Remoting. I had formerly considered JMX to be one of those specs that was almost certainly relevant to someone else, but I didn’t see it as having much utility in my own contexts. Sheesh, was I ever wrong! JMX and the monitoring tools it enables aren’t exactly new. In fact, I believe the functionality I am just recognizing was already fully enabled in Java 5; I’m not sure. Nonetheless, Matt and I have now awakened to the advantages of having attachable JVMs on all our live server deployments, and there is apparently no significant overhead in cpu or ram resources for having them. In short, we can connect to any of the JVMs hosting our various application server instances any time we want, and we can transparently monitor and control JVM heap, threads, and numerous other parameters that expose themselves via the MXBean interface. It’s much more powerful than I had realized. As web developers, one of our recurring challenges is to get useful data about how our applications perform under real-world load conditions. We certainly endeavor to load test our development servers brutally in anticipation of what you guys will do when we deploy, but there’s no substitute for the real thing. Our newfound ability to connect to the hot, running JVMs for Javalobby, DZone or JRoller to see how they are managing threads and memory has already proven indispensable. We obtained more hard data and helpful insight in a week of regularly using jconsole and jmap than we had previously obtained in months of general observation. They helped us kill bugs dead. <grin> Using jconsole you can easily monitor how the various parts of the Java heap are allocated (with names like “Eden”, “Survivor Space” and “Old Gen), when they grow, and how and when they are cleaned up by the garbage collector. Additionally you can see every thread in your application and explore its state and call stack. With jmap you can get a heap snapshot any time without killing or disrupting your running application, and the “jmap –histo” command might be just what you need if you’re trying to figure out which classes are chewing up all your memory. If you haven’t used jconsole and jmap to watch how your live applications consume memory and threads, then I urge you to give them a try. They are great tools that I wish we had not overlooked here for so long. I guess Java isn’t always better
As I promised last week, I need to tell you about an embarrassing moment where a switch to Java did not necessarily enhance an application which had been running successfully for years. Javalobby, DZone and our other Java-powered sites all run on the outstanding J2EE application server, Caucho Resin. Recently we updated from their 3.0.x series to their newer 3.1.1 version. Resin 3.1.0 was released back in December of last year, but it required configuration file restructuring we didn’t want to do until recently. Older versions of Resin had a perl-based “watchdog” script to launch and monitor the actual Java application server, restarting it if necessary. The perl watchdog worked well and occupied only about 3.5 megs of resident ram to run. Beginning with version 3.1.0, however, Resin switched to a new Java-based watchdog process. To be fair, I think the Java-based version may actually do a little bit more than its perl predecessor, but I was astounded when we saw that the Java watchdog was consuming over 250 megs of resident ram in its default configuration on our server. I know ram is cheap, but that’s still a lot to give up when you’d prefer to give your applications as much headroom as possible. We studied the finer points of the configuration files documentation and were successfully able to supply appropriate JVM startup arguments to shrink it all the way down to only 128 megs of resident ram. We tried to shrink it further, but the watchdog process would barf with out-of-memory exceptions instead of launching the actual application server. As far as we can tell, the Java process isn’t really doing a whole lot more for us than the perl watchdog did, but it occupies well over 30 times as much memory to do it. I hope you’ll appreciate that we have affectionately renamed the Java version “WatchPig” to acknowledge the bloat. I think this is one of those cases, rare as they are, when Java isn’t necessarily better! Until next time,
Rick Ross
rick@javalobby.org
AIM or Yahoo Messenger: RickRossJL | | |
| | |
| | | Matthew Schmidt
is the man behind the scenes at Javalobby. If you have questions
or concerns, feel free to email him at matt@javalobby.org. |
 iPhone 3rd Party Apps - Puulllleeeasssee!
Yesterday brought the long awaited annual WWDC in San Francisco and the announcement of a super cool dev kit for the iPhone. Or not! This super cool support for iPhone third-party applications is none other than support for Ajax via Safari. To help support this, Apple also took the time to release Safari for Windows (along with a few security holes too). There were lots of claims about how fast it is in comparison to other browsers, and while I won't deny that it’s a pretty speedy browser, it's also not very accurate. Most people I know don't really use Safari on their Macs. It's rendering accuracy leaves something to be desired and as many people across the web have mentioned, it can be buggy at times.
Of course, does any of this really matter? Not especially. This support for third-party apps via Ajax is probably a little third rate, but it gives Apple a chance to point to developers and say, "Look, we're listening. Now, go buy one." Without a doubt, there will be lines here in the US for these things and I'm sure at least one of us here in the office will have one before too long. 0-2g in 3.5 seconds?
If we were talking about cars, going from something like 0 to 60 in 3.5 seconds would probably be an excellent metric to be quoting. Unfortunately, we're not talking about cars; we're talking about the memory usage of Java application servers. Of course, I'm exaggerating a bit about how fast the memory usage climbed, but as Rick mentioned in his column we've been doing some serious soul searching lately with our applications as we migrate to newer hardware. These days, it seems that software developers take having an abundance of memory for granted. Start an application server, lose a gig of memory. Start up a cluster of 5 mongrel servers for rails, lose another 300M. It all seems like too much. Now, I'm not one to throw stones in a glass house. DZone is just as bad an offender as some of the other software we use, and I'd say that it may quite possibly grow the fastest (but eventually level off). The other side of this rant is that part of the problem may just be the Java VM. It is a finely tuned machine and you have to treat it as such. We went through many iterations, and found that if you throttle it down too low, you can make it stall out. Tweak it too high and you end up with a VM that grows to take up all your resident memory. You see, Java is happy to grow and fill up the entire heap that you give it. If it doesn’t need to garbage collect, why should it? There are lots of tutorials out there about tuning your VM, so I won't get into the details here. With the right tuning, you can get a lot more mileage and stability out of your VMs and might even be able to continue using that same old server you thought you needed to toss in the trash. Red Hat Cools Off This Summer With a Little IcedTea
It seems that the OpenJDK project got a little bit of support last week as Red Hat announced a new project to replace the binary-only bits in the OpenJDK with code from GNU Classpath. The project is called IcedTea and Mike covered this story nicely at Javalobby on Friday. I think it's good to see the promise of support from the open source community regarding OpenJDK finally being made good on. Red Hat has also said that they will be contributing their changes back to the OpenJDK project once all the technical and legal details are worked out. While Red Hat has said this isn't a fork (it doesn't contain any OpenJDK code), some are saying that it smells like a bit of a fork. This is the nature of the Open Source movement though and with any luck the changes that they make will be accepted back into the core OpenJDK repository and replace the last stragglers of binary code. What are your thoughts on this project? Was it a good idea or just the start of what many of the open source detractors had feared in the run up to Java being open sourced? Share your thoughts at Javalobby. Until Next Time,
Matthew Schmidt
matt@javalobby.org
Yahoo IM: mattschmidtjl | | |
| |
| | | most clicked this week from dzone.com |
Most-clicked links this week |
| |
|
| |
| | | A recap of
some of the most popular and active Javalobby.org
discussions this week. |
|
Lets convict MS quickly
|
Rick's "Lets not convict MS too quickly" opinion is way off base. Just because MS can do it, doesn't mean they should. Rick's article only gives cover and we need to be clear about what's right.
| |
Full Discussion |
Posted By: Doug Whitehead - (78 Replies)
|
|
Move Over Eclipse. NetBeans 6 Rocks!
|
Over the last several days, I have been working in NetBeans 6, m9 preview. In a nutshell? This is a major improvement over NetBeans 5.5. Not just a minor upgrade. Is it time for Eclipse to move over?
| |
Full Discussion |
Posted By: Michael Urban - (71 Replies)
|
| |
| | | Technical papers & research related to Java development. |
| Product and
service announcements for Java developers. |
|
JxCapture EAP2 Build is Out
|
EAP2 build of JxCapture, a cross-platform library that provides a comprehensive screen capture API for Java applications. EAP2 introduces serious performance improvements and new features.
| |
Full Announcement & Discussion |
Posted By: Eugene Toporov - (0 Replies)
|
|
TinyLaF 1.3.7
|
TinyLaF is a free Java Look and Feel (LGPL) which looks somewhat similar to Windows XP. This release fixes all known bugs and introduces some improvements (especially for FileChooser component).
| |
Full Announcement & Discussion |
Posted By: Hans Bickel - (0 Replies)
|
|
LiquiBase 1.0 RC1
|
LiquiBase 1.0 RC1 has been released. LiquiBase is a database change/refactoring management tool that is designed to work with multiple developers and code branches.
| |
Full Announcement & Discussion |
Posted By: Nathan Voxland - (0 Replies)
|
| |
|
Back to newsletter list
Perspective
