What has changed? The most visible changes are related to usability. Before 3.0, Plumbr was packaged as a desktop/server software that you needed to install on every workstation separately and the user interface (UI) was limited to that workstation. From today on, Plumbr is offered as a Software-as-a-Servise (SaaS) solution. This means that all your JVMs, performance metrics and leak reports are now gathered in one easily accessible place.

Read on for a more detailed description of the new UI and a sneak peak into Plumbr future releases!

So what the heck is happening under the hood? Why is the process consuming more memory than you allocated? Is it a bug or something completely normal? Bear with me and I will guide you through what is happening.

In order to discover all the new look and feel, register yourself to get your hands of the latest release and access the new user interface. If you are an existing user, generate yourself a password using the same email address you used during the registration.

This is going to be another story sharing our recent experience with memory-related problems. The case is extracted from a recent customer support case, where we had an issue with an application dying with OutOfMemoryError messages in logs. After running the application with Plumbr attached we were sure we were not facing a memory leak this time. But something was still terribly wrong.

Lessons learned?

• Do not let integration details cross system boundaries

• Redundant data will cost you. Remove it whenever you can.

• Primitives are your friends. Know thy tools and learn Trove if you already haven’t

• Be aware of the optimizations provided by your JVM

• Automate builds. Plumbr release has to be built without any manual intervention.
• Automate tests. Plumbr release has to be verified automatically using different testing techniques ranging from unit to acceptance tests.
• Automate infrastructure. Build infrastructure has to be able to launch and destroy the server instances used to build and test Plumbr automatically.
• Provide transparency. Whether it is a functionality implemented or bug fixed - we need to know in which versions this change is present. If an exception is thrown, we need to be able to map the obfuscated stacktrace back to the actual source code using the correct version of the obfuscation map.

Lets start with our goals in mind. Among other goals we are aiming towards, the one adding vasts amounts of complexity is the number of platforms we need to support. If you have thought that for Java it will all be about Write Once, Run Anywhere then - make a second guess.

It all falls apart the very same minute you create something truly low-level and optimized to the last possible bit. Suddenly all kind of unexpected small details start to matter, such as the garbage collector selection, minor differences in the classloader implementations or the way JVM vendors have decided to interpret certain parts of the JVM specification.

I have just recently returned from JavaOne Russia conference. JavaOne is one of the biggest and the most known conferences for Java developers. The event held in Moscow draw the attention of about 3,000 participants. I was selected to present their my talk about "Multi-platform Java application development". I will convert that talk into a blog post in near future, stay tuned.

But what I would like to share with you today are my impressions of this conference. Being a speaker gave me a really good opportunity to see the event from the different angles:

Continue reading on Plumbr blog]]> http://plumbr.eu/blog/how-to-create-a-memory-leak?utm_source=rss&utm_medium=rss&utm_campaign=rss20130619 http://plumbr.eu/blog/how-to-create-a-memory-leak#disqus_thread Tue, 23 Apr 2013 09:50:30 +0000 Ivo Mägi http://plumbr.eu/blog/?p=1151

This is going to be a rather evil post - something you will be googling when you really wish to make someone’s life a misery. In the world of Java development memory leaks are just the type of bugs you would introduce in this case. Days or even weeks of sleepless nights in the office are guaranteed for your victim.

We will describe two leaks in this post. Both of them are easy to understand and reproduce. The leaks originate from the real world case studies, but for the sake of clarity we have extracted the demo cases to be shorter and simpler for you to grasp.

But rest assured - after we have both seen and fixed hundreds of leaks - cases similar to those demoed this are more common than you might have expected.

We have recently posted data about application server market share we gathered from the free Plumbr deployments. And it resonated well - via different channels we got hundreds of comments and opinions on how to interpret the data.

But one of the arguments in its different forms kept coming after us through every channel. Whether it took the form of “Tomcat is not an application server” or “This data is irrelevant as it is not focused on real application servers such as Weblogic or WebSphere”, it just kept surfacing.

I made us wonder - why does Java community have so different opinion abou what actually is an application server. So we decided to shed some light upon the issue. Looking into the most obvious source - namely Wikipedia - and things do not look too bad:

First post in the series analyzed the foundation - on what OS the JVM is run, whether it is a 32 or 62-bit infrastructure and what JVM vendor and version were used. Second post focused on the different application servers used. The one you are reading now sheds some light upon the heap sizes used by Java applications.

Full disclosure: no customer data was exposed during the attack and no Plumbr executables were harmed during the attack.

The sad news is also related to the maturity of this functionality - we announce that starting from April 8th, 2013 the permgen leak reports will no longer be available for free. So - take the chance while it is still possible, download Plumbr and get rid of all your existing permgen leaks without us charging you a dime.

• MySQL drivers launching background threads
• java.sql.DriverManager not unloaded on redeploys
• BoneCP loading resources from the wrong classloaders
• Datasource registered into a JNDI tree blocking unloading
• Connection pool using finalizers tied to Google’s implementation of reference queue running in a separate thread