yunt.net

The last day was pretty chaotic with our flight status changing throughout the day. The only complete session I attented was Managing Your Application’s Performance Into Production. It was one of my favorite sessions as it wasn’t too commercial, yet not just abstract solutions are J2EE spec. experts are fond of doing.

Basically the topic was monitoring, and how to achieve a balance between visibility and performance overhead. (think Heisenberg’s uncertainty principle). The more instrumentation, the bigger the performance impact – even if it’s trivial the fundamentals remain. The presentation was sponsored by Veritas (recently acquired by Symantec I learned) and briefly mentioned how they achieve this goal.

Using a pattern they call “Adaptive Instrumentation”, the profile execution stacks and identify the best intrumentation points in code. Their instrumentation is done dynamically at runtime using aspects. Many other sessions I attended involved using AOP to achieve different things. The most favored solution today is using some form of class loader magic. While the specifics may vary by implementation, it goes something like this:

An “agent” has a listing of code points to instrument. At class loading time, the agent intervenes and provides an instrumented version of the class as it’s loaded. There are some real benefits to this approach:

1) no special build is required. You can used the RC or production bits as desired
2) restarting the app is all that’s needed to “undo” the instrumentation – this makes it somewhat reasonable in some production environments (easy rollback)
3) there’s no deployment changes – no classpath trickery (think Clover) or jmx hooks needed.

The single biggest theme I’d like to apply is “don’t assume test outcomes or usage patterns”.
Too often we *think* we know what sort of traffic to use during load tests. Maybe historically production purchases have been 70% red products, and 20% blue products – while that’s a decent place to start, if the market suddenly shifts and everyone is buying purple we could experience a largely untested usage scenario.

Using this Veritas solution one can make reaction based (think IRT) investigations more productive. The evil code is profiled instrumented and we effectively are provided with debugging like output that can even show values and state of the the stackflow.

Last night I attended the famous Collection Connection BOF hosted by Joshua Bloch. As he was the original author of most of the Java collections framework, it was really interesting to hear him discuss the lineage of the packages. There was a quick overview of new collection features in Tiger (1.5.x) and much more detail on material in Mustang (1.6.x) and even some peeks at Dolphin (1.7.x.). One common trend in collection evolution is with Exceptions. By Mustang, a new set of collection interfaces will be introduced, most of which have 2 sets of accessor method pairs: one set would throw an exception, while the other would return a special return type. Think of it like this:

someMapType.get("foo"); //throws an exception is there's no key "foo"
someMapType.retrieve("foo"); //returns null, 0, etc.

Today is all about JMX. I’ve already attended one session and have 2 more on the subject. Some really new patterns proposed, but these guys are mostly discussing “Dolphin”, which is optimistically 5 years in the future before our appserver vendors will certify against them.

Developing Scalable JMX
Given that we normally think of monitoring when we think of JMX, this session was a refreshing surprise. The discussion was centered around using JMX for actual “management” of an application. This includes deployment, configuration and life cycle control (think of MNAD’s control node).

Here’s the problems that drove this work:

Managability speeds the development cycle

I’ll follow up with reviews on the remaining events later.

J2EE Connectors Demystified
This was an overview of using resource adaptors as an alternative to JMS destinations. They covered both inbound and outbound implementations. The “inbound” patterns were much more familiar to me, as they involved MDBs processing messages (like our OSN).

An outbound connection is a mechanism to connect to external systems. There’s a great deal of connection management: pooling, creation etc. It’s possible to export transaction contextas well as export a security context to an EIS.

An inbound connection is a mechanism to consume external messages. It’s able to import a transaction context from a remote EIS. There is not importing of secutiry context for inbound connections in the spec.

There was a lot of time spent on XML descriptors and other details which I found tedious during the presentation. Someone with a strong JMS background may have got more from this. The presenters did provide a URL for further reading:

http://genericjmsra.dev.java.net

JVM Support for Aspect Weaving
This presentation was hosted by BEA’s JRockit team and the founder of Aspectwerkz. It was a very interesting area of research. The went over various approaches to AOP, describing pros and cons for each.

There are 3 basic approaches to instrumenting AOP:
1) statically: source or byte code level (think build time) – but has dependency issues for late binding types
2) load time: this is achieved using classloader magic
3) run time: byte code level, redefine a class on the fly – hotwap the definition (could make a mess of the JVM’s permanent generation memory if you ask me)

The solution proposed by the speakers was to handle all this at the JVM level. The main benefits to this are:
1) more efficient, as the amount of “bookkeeping” is reduced significantly
2) multiple AOP agents may safely coexist, else they could re-instrument each other’s aspects

Other:
Class loader security – your Aspect subscriptions can only work in *your* class loader. To fake this out, I believe you can just inject at the bootclasspath loader and have free roam of the entire JVM. I’ve requested they email me when a JRockit prototype is available in the coming weeks.

Clustering Consistency and Caching
Anyone who’s studied caching in an academic setting probably knows the fundamentals for this. The part that I paid attention to was how a clustered application (weblogic) can broadcast its cache in over multicast. Like many things, there’s a balance. You can trade off between consistency of data or application performance.

For futher reading google the following:

Butler Lampson
Paxos Made Simple
Distributed Algorithms in Java

Java Platform Clustering
I bailed out of this on early. It’s not J2EE or application clustering, rather “beowulf” style clustering. They want a single logical JVM running across physical machines. I’m badly in need of fresh air and caffeine, so am going for a walk through the city.

I’m in a rush, but here’s the days takeaways.

Web Services in the real world by eBay
This was a shameless plug for their API business. Basically they want developers to drive traffic to them

Chasing 9s
Very theoretical, statistical based explanations of “what is availability” and how to measure it and other factors.

Availability = MeanTimeToFailure / (MeanTimeToFailure + MeanTimeToRecovery)

They also suggest that a higher MTTF will compensate for a lower MTTR. Not sure I completely agree. I guess math can’t perfectly model real world failures as much as the presenters would’ve liked.

Continuous Integration with JFCUnit, CVSNT etc.
I had to walk out of this one early. I can get over the Swing/Windows aspects of the presentation, but over 30 minutes were spent convering the installation of windows tools. It turns out his development team consisted of 5 developers. I asked him some questions on how this model would scale with a larger project and he wasn’t sure. His team even employed timing hacks to test SWING GUI applications (repeat a test until it passes or a timeout is reached)….

javadoc JSR 260
If you want to watch a live flamewar, attend a JSR debate. I didn’t stay for the entire Q&A as I had to walk a few blocks to my next presentation. A big item of debate was doc inheritence. Apparently some developers wanted to avoid rewriting docs when they extended a class. The trouble was, there are other contexts where something is inherited, such as implementing interfaces, abstract classes etc.

I stood up and made a comment that there should be no default doc inheritence, since an incorrect assumption could be worse than no docs at all. I can elaborate later.

Ensuring 100% J2EE portability

Debu Panda is the man – makes me want to give Oracle more money (almost). I’ll definitely give a brown bag at work for this, but here are some highlights:

Challenges when ported across J2EE servers:
1) dev env. may differ from exec. env
2) some platforms get neglected during test
3) vendor cert. of 3rd party components
4) no consistent class loading behavior in J2EE spec.

Tips:
1) check out AVK, which validates for J2EE compliance – could be done at build time perhaps
2) avoid hardcoding vendor lookup mechanism (BEA’s t3://)
3) avoid hardcoding XML parsers (use JAXP)
4) don’t depend on class loading behavior of a particular server
5) tuning params are NOT part of J2EE
6) to solve the CMP descriptor portability problem, hurry up and wait for EJB 3.0

I need to run and stand in line to hear Scott McNealy rant about something entertaining. Later…