Shashi Velur’s blog

Today, during load testing I saw one of those dreaded “java.lang.OutOfMemoryError: PermGen space” errors on our fairly large web application deployed in Tomcat running on Sun JDK 1.5.

We used to use the default (64m) for the perm space. I bumped it to 128 for now, until I can find some time to dig into this using JProfiler and JHAT.

I will be particularly looking at the amount of our classes loaded from WEB-INF/classes dir (we have a lot of generated classes from legacy code), Static references in our legacy code, Spring AOP/Hibernate CGLib usage and ThreadLocal usage in our application.

I found some useful information here:

• http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
• http://my.opera.com/karmazilla/blog/2007/09/29/return-of-the-permgen
• http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
• http://blogs.sun.com/sundararajan/entry/querying_java_heap_with_oql

Technorati Tags: OutOfMemoryError, Performance tuning

I think the Java developers (especially server side developers) have started looking at OSGi as the next-generation Java Middleware technology. This may not come as a surprise because of the adoption of OSGi by the JEE server vendors and Java (server, desktop and embedded Java) community in general.

OSGi technology:

1. Enforces better componentization (separation of concerns) than most existing techniques in JEE (Using one classloader per bundle).
2. Provides versioning of components and the ability to deploy multiple versions of the same components in the same VM, unlike JEE.
3. Unless you use one ”component” for your entire application/product, OSGi enforces SOA for components using dynamic services (or “Extensions”/”Extension points” for those wanting to use the old Eclipse standard).
4. Enforces loose coupling of components (using a publish/find/bind service model).
5. Forces the resolution of application dependency problems (requiring explicit declaration of dependencies between components).
6. OSGi ”fixes” Application server hot-deployment functionality (ability to deploy/undeploy software components without requiring the Server/JVM).
7. There are multiple opensource OSGi implementations available:
   • Equinox / Eclipse
   • Felis / Apache (Oscar)
   • Knopflerfish / Makewave
   • Concierge
8. OSGi implementations are quite stable with many applications/servers using or running on them.
   • Ricoh has been shipping Printers with OSGi since 2005.
   • BMW 5 series cars ship with OSGi.
   • JBoss, IBM WAS and BEA Weblogic servers are adopting OSGi.
   • Sun’s Glassfish uses OSGi
   • SpringSource dm server is built on top of OSGi.
   • Mule ESB
9. The OSGi implementations generally have a small footprint (With OSGi Jars that are less than 500 kb).
10. OSGi has proven itself in the embedded and desktop application world too. The open source Eclipse IDE has been based on OSGi since 2004.

Technorati Tags: Java middleware, next generation technology, OSGi, OSGi middleware

Ferrari has been steadily growing over the last 10 years. Ferrari California is a new model line that will push this further. What struck me is the innovation here:

• This is Ferrari’s first ever V8-powered front-engined car with the first-ever retractable hard-top.
• This car has the lightest and the fastest retractable hard-top in it’s category - it opens and closes in 15 seconds. It weighs less than the soft-top featured on any Ferrari ever created.
• Boasts the lowest ever drag coefficient (0.32) for a Ferrari car.
• First Ferrari to have direct-fuel injection and twin-clutch gear box.
• Most fuel-efficient Ferrari (21.5 MPG), but still revs up to 8000 RPM and still matching the Torque/Engine capacity ratio of the previous generation BMW M3 CSL.
• This is the most comfortable, best balanced, best manner Ferrari ever for everyday driving.

Wow..!

No wonder these cars are sold out until the end of 2010 even if you can shell out over $250,000.00..!

Technorati Tags: Ferrari, Ferrari California, Innovation

I am currently working on performance tuning & refactoring a product. And, interestingly I found some Agile/Lean principles that apply for performance tuning and refactoring:

• Most Lean principles appear counter-intuitive at first
• Aim for system optimization instead of point optimization
• Build prototype and measure (run quick experiments), not just theorize
• Minimize the number and size of things-in-process
• The most predictable performance comes from maintaining options until you have the most information

Technorati Tags: Agile, Lean principles, Performance tuning

One of the projects that I am currently working on is a Dual-API SDK. This “Framework” has two APIs (or “sides”) - Client API and the SPI (Service Provider Interface) API.

The Client API provides the ability for the Client to deal with various kinds of Artifacts (Requirements, Tasks, CRs, etc.) without paying attention to which “Repository” they came from. Meanwhile, the SPI API provides the ability to ”implement” and “register” the “Providers” (corresponding to various “Repositories” that implement a subset of the SPIs).

Once these SPIs are “registered”, it becomes possible for the “Framework” to provide the “CRUD” operations for the appropriate Artifacts from the “Repositories” that support the given Artifact type(s).

The following requirements decided the backbone-technology to be used for this “Framework” product:

• Ability to dynamically register and un-register SPIs (corresponding to various “Repositories”).
• Ability to support multiple versions of the same SPIs co-existing in the same runtime environment.
• Support modularity of SPI implementations and loose coupling between various modules.
• A low cost (or possibly free) server with a license that allowed us to bundle it with our “Framework” product.
• A Java-based technology.

The most suitable technology for this turned out to be OSGi. This was a suprisingly easy choice. The only other option that came close was Mule 2.0.

Technorati Tags: Java Versioning, OSGi, SDK Development

I had an opportunity to attend a one-day lean manager’s workshop (by Mary and Tom Poppendieck) organized by my employer at my workplace.

It was so much different than the other similar workshops I attended in the past:

• The whole talk was so cohesive - Mary and Tom constantly focused on a few core principles approaching from various perspectives. They arrived at the very same conclusions by using examples and data from various Industries/Verticals in a very lucid style.
• Another thing that resonated with me was the application of Scientific principles from Queuing theory, Fluid dynamics and emphasis on using actual measurements as data to improve. Also, they used some examples/directives from the Military/Army manual (on communication) and applied them to Lean/Agile Software development.

I will be blogging more about what I learnt and how I plan to apply them at work.

Technorati Tags: lean software development