Comments on: SCA, OGSi and Spring from an IT management perspective

By: William Vambenepe

William Vambenepe — Mon, 14 Apr 2008 20:33:51 +0000

You must be very tall, Liverath.

By: Liverath A.

Liverath A. — Mon, 14 Apr 2008 19:22:04 +0000

do we really need a name for the combination of osgi, sca and spring? whenn you put the toaster on the top of he refrigerator to save space in the kitchen you don’t start calling them different, do you?

By: Jean-Jacques Dubray

Jean-Jacques Dubray — Mon, 25 Feb 2008 15:42:31 +0000

How about SEE? S(OA) Enterprise Edition,

JJ-

By: William Louth

William Louth — Mon, 25 Feb 2008 15:36:20 +0000

Speaking of meta-data (and previously CMDB) what are your thoughts on JCR. I see that JBoss DNA http://labs.jboss.org/dna/) is going to use it as the standard for its information management system. This was something I pushed hard at OpenView in 2004 when they started talking (and talking) about building a federated CMDB solution.

http://www.theserverside.com/news/thread.tss?thread_id=45763#234732

The implementations of the JCR specification leave a lot to be desired but I do like the specification and programming model with some minor exceptions that I hope will be fixed in 2.0.

By: William Louth

William Louth — Mon, 25 Feb 2008 11:58:30 +0000

Correction: “I would hate to be the operations person tasked with looking at data generated solely from call stack samples WITHOUT runtime context and a reference application behavioral model.”

By: William Louth

William Louth — Mon, 25 Feb 2008 11:57:31 +0000

http://www.oracle.com/technology/products/oem/pdf/wp_productionappdiagnostics.pdf

FUD 1: “Many Java diagnostics tools in the market are based on Byte Code instrumentation (BCI) technique that requires application instrumentation. It requires in-depth understanding of the application to know which Java components to instrument. In addition to the application knowledge, it also requires specialized skills to use the tools to instrument the application. BCI based tools have high configuration overhead and also add significant performance overhead…. ”

Configuration overhead? With JXInsight you only have to drop an instrumentation extension pack library into the class path of your server. Runtime overhead? With metering strategies we can deliver the lowest level of overhead whilst providing accurate data which is not the case for sampling.

Note: Most experts in the performance field (especially those familiar with SPE) know that performance problems cannot be resolved without ** first understanding the application **. That is why performance engineering starts early in the application life cycle recording trace execution paths which are then used as reference when viewing higher level and lower overhead performance data (probes) within a production environment. I would hate to be the operations person tasked with looking at data generated solely from call stack samples with runtime context and a reference application behavioral model.

FUD 2: “[BCI Tools] They also do not provide visibility for transactions across the Java and DB tiers. All these reasons make the BCI based tools unsuitable for diagnosing application problems in production environment.”

JXInsight’s Transact (JDBInsight) is the ** only ** solution on the market that relates database transaction patterns (sequence of SQL operations within a XA/Non-XA transactional context). All other tools simply relate an database operation to an entry and exit point (http request) we actually have a transaction manager within our runtime mimicking the operation of a real transaction manager. We can point out multiple resources transactions within a single business transaction (entry-exit) and we can do this across all databases and not just Oracle.

You know some of us in the industry do care about how we have tackled and solved such problems.

By: William Louth

William Louth — Mon, 25 Feb 2008 11:36:00 +0000

By the way I am all for meta-data. JXInsight was the first contextual execution trace solution for Java offering more than a code level view.

By: William Louth

William Louth — Mon, 25 Feb 2008 11:34:32 +0000

One of the reasons we have a large amount of tooling for performance analysis of Java EE applications is because there was finally a standard component architecture and set of supporting service specifications used by developers that had a sufficiently coarse grain interface suitable for instrumentation. It was relatively easy to create a management solution around a few standard component interfaces (EJBHome, EJBObject). Unfortunately not everyone understood the difference between a component and class and hence the overhead for teams both during development and at runtime. Spring approached this problem by recognizing that most people will never be able to make the distinction clear enough and delivered ** some ** similar services but at a smaller cost. Unfortunately this has resulted in an excess of service interfaces with some CMS solutions requiring 500 Spring POJO’s to be created on start-up just to access a simple PDF document. How does one now provide a performance management solution for such architectures as the granularity of the interfaces various so much (much more than EJB). Is is now very hard to offer a bog standard out of the box experience (low overhead) without a large amount of tuning of instrumentation levels (exclusions!).

By: vbp

vbp — Sun, 24 Feb 2008 22:23:12 +0000

Hi William L.

Is it the parenthesis in which I point to AD4J that set you off? I am trying to make sense of your comment in the context of what I wrote in the article. The article is not about comparing the different approaches to java perf management. And I don’t see any BCI FUD in there.

The point I make is that many techniques have been developed for java management (especially in the performance management area) that together provide an unprecedented level of visibility into performance aspects. But that new opportunities are created (not just in the perf mgmt side) by the metadata made available through the use of such techniques as Spring, SCA and OSGi.

They don’t in any way replace the existing perf mgmt techniques, but they allow these techniques to be used in a more contextualized way. And again, it’s not just perf mgmt. The value is even more immediate for cross-process instance monitoring, SLA, dependencies, root cause, etc.

By: William Louth

William Louth — Sat, 23 Feb 2008 14:46:03 +0000

Oh no not more talking up of Spring over standards such as Java EE and then to actually claim a still in beta product that uses call stack as a ideally suitable for production over byte code instrumentation based approaches that can accurately relate work to a transaction context and database operations. I am really shocked and disappointed. When I read the BCI FUD in the Oracle white paper I assumed it was just some Oracle marketing person misinterpreting or overstating a benefit of one particular narrow approach (note: one approach is never sufficient in the enterprise context) to performance management.

Now I would dearly love to show everyone how far off this one is but unfortunately the license of the software restricts any benchmark publication. All I can say is that obviously someone has never considered the typical call depth (>200) of Java EE/Spring applications (hint: deeper -> higher overhead) and tested this with an application having a sufficiently high number of active threads. Not to mention that it is impossible to determine maximum times so important for performance engineers focusing on user experience with such a simple approach.

For your information one does not have to trace every event and instrument every method. Trace instrumentation techniques including proxying and BCI (AOP) can easily out-perform thread call stack sampling whilst providing accurate measurement and diagnostic data (argument, target object state) you just need to think outside of the box - metering strategies.

Probe Metering Strategies
http://blog.jinspired.com/?p=190

If you are up for a public benchmark (shoot-off) of performance management tools and techniques then please accept my participation.

William