Glassbox Inspector Performance Monitoring Project Announced

Discussions

News: Glassbox Inspector Performance Monitoring Project Announced

  1. The Glassbox Inspector has been released in alpha. Released under the Common Public License, it combines AspectJ and JMX for a modular approach to monitoring performance for enterprise systems, providing correlated information to allow you to identify specific problems. It lets you capture statistics such as total counts, total time, and worst-case performance for requests.

    The release was announced today along with an IBM Developerworks article entitled "Performance Monitoring with AspectJ, Part 1."

    I'd love your feedback on the article and the project!

    Threaded Messages (24)

  2. Spring AOP and JXInsight Trace Extension[ Go to top ]

    Hi Ron,

    Instead of creating many different approaches (and now tools) to tracing with AOP the AOP community should be defining a standard specification that allows for different implementations and integrations.

    When I was busy on the AspectJ newsgroup I requested that instead of reinventing run of the mill AOP patterns (tracing, tracing, security, and tracing) that a specification be defined that allowed for dynamic runtime and tooling integration.

    I do not think we need to reinvent every trace integration again in AOP. AOP cannot be the only source. Today develoers can in theory have distributed tracing with CORBA, Weblogic RMI, HTTP (SOAP), JMS, and JBoss Interceptors.

    Spring AOP Tracing with JXInsight Insight Article:
    http://www.jinspired.com/products/jdbinsight/springtracing.html

    We (http://www.jInspired.com) are currently putting the finishing touches to JXInsight 4.0 which comes with out of the box integration for many technologies including: JNDI, JMS, Spring, Hibernate 2/3, EJB, JMS, JTS/JTA, JDO, Servlets/JSP, JCR, WorkManager/TimerManager, JDBC, CORBA, RMI, JBoss, Weblogic Tracing and JCR.

    Whats New in JXInsight 4.0?
    http://www.jinspired.com/products/jdbinsight/downloads/new-in-4.0.html

    Developers today can create custom trace extensions and have integration with an award winning UI console (JXInsight Console) with metrics that go far beyond low resolution wall clock times. JXInsight's Tracer collects the following statistics: high resolution wall clock, GC time, CPU time, thread blocking and waiting times, object allocation sizes for trace intervals. We have done such a integration for teams in HP OpenView.

    We will also be announcing an AspectJ trace extension post the 4.0 release.
     
    Regards,

    William Louth
    JXInsight Product Architect
    CTO, JInspired

    "JEE tuning, testing, and tracing with JXInsight"
    http://www.jinspired.com
  3. It's Not Tracing[ Go to top ]

    Hi William,

    This article is not about tracing at all! Rather, it shows a pragmatic and efficient way to utilize AOP for monitoring performance, and demonstrates how you can go beyond simple tracing to build integrated solutions with AOP. I provide correlated information with real-time data access that allows you to capture relevant context data. This allows capturing information based on runtime conditions like the presence of errors or anomalies. I also show patterns like automatically exposing objects for JMX management, and (in part two), preventing errors in monitoring code from affecting the underlying application

    This really showcases the power of the full AOP approach and the cleanliness of it as opposed to wiring in lots of interceptors.

    I like the JXInsight GUI and it would be great to integrate it with this kind of next generation facility for correlated data monitoring.
  4. How about the extra overhead?[ Go to top ]

    Hello,
    This is a pretty nice idea. I did the same thing for our internal use using AspectJ and JMX. But I wonder how much overhead its going to add on a production server. Anyone used glassbox in a real production system or atleast estimated the overhead? Its good if it incurs only little overhead. Does glassbox supports disabling aspects at runtime?
  5. Low Overhead and Dynamically Enabled[ Go to top ]

    Hi Sri Sri!

    From preliminary measurement, I have found the overhead for end-to-end response time to be unmeasurably low for simple queries. I am still setting up a proper benchmark to test under load, and will be publishing the results in part two. I believe the reason for this is that we do limited amounts of work that are dwarfed by network calls, IPC, and disk access.

    However, at this stag the biggest performance impact I see is the extra time to start up due to load-time weaving. For example, it takes about five seconds to start an instance of Tomcat with 3 apps on my Windows box without the Inspector and about fifteen seconds with. This is using JRockIt 1.5.0_02, which is about twice as fast (!)

    And glassbox fully supports disabling aspects at runtime with a JMX interface (naturally). That functionality is already in the code base and will (again) be described in part two!

    Also, it would be great to get your input on the approach we used in the Glassbox Inspector, and any lessons you learned.
  6. Low Overhead and Dynamically Enabled[ Go to top ]

    This is using JRockIt 1.5.0_02, which is about twice as fast (!)

    Twice as fast as what?
  7. JRockIt compared to the Sun VM[ Go to top ]

    I was comparing BEA JRockIt to the Sun VM. On my Windows XP machine Tomcat 5.5.9 with these apps loaded starts on a JRockIt 1.5.0_02 VM in about 15 seconds and it starts in 25-30 with a Sun 1.5.0_02 VM.
  8. Its Not Tracing. Are you sure?[ Go to top ]

    Hi Ron,

    I think we can a disconnect on the word tracing. To me tracing is the very act of (event) data capturing which is prerequisite for performance manangement (profiling).

    Tracing is about understanding the flow of requests through a system and associating as much contextual information ("context data", "errors") as possible whilst recording metrics for trace intervals or a run of traces ("patterns"). When tracing is "simple" then it is logging.

    "This really showcases the power of the full AOP approach and the cleanliness of it as opposed to wiring in lots of interceptors."

    Sorry, but this ignores the difficult and error prone effort that goes into defining pointcuts that might be portable across implementations of a technology standard. An interceptor can make the integration simplier, portable and in some cases performant. For example many containers proxy standard interfaces for resource management and monitoring. Distinguishing between a real driver and a wrapped driver is difficult and costly. Interceptors can also allow safe and controlled injection of tags into remote request's payload. Additionally interceptors exist today with the ability to control the injection (servlet filters and filter mappings) without recompiling/weaving aspect code.

    Regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  9. Its Not Tracing. Are you sure?[ Go to top ]

    William

    Ron' Glassbox is using the new AspectJ 5 load time weaving capabilities which means there is no explicit compilation / weaving required by the user as you seems to argue. It is just required to add one single JVM flag (-javaagent) and deploy the application (any application) as usual with aspects alongside the classpath. I guess the very same requirement stands for JXInsight since I guess you are also doing bytecode manipulation don't you ??.

    I like the GlassBox approach for its technical value (I am not neutral here as an AspectJ committer). I do agree with you that the tracing / APM landscape is way too crowded. JXInsight is just one among many many many that almost pops up everyday (actually at every conference booth floor I have been I have always find new ones I never heard about).
    So far none has been using AOP to my knowledge. GlassBox attempt in that direction will tell us if this choice is good, and perhaps will drive others product in the same direction at some stage.

    Alex
  10. Java5, AOP, Compiliation, Companies[ Go to top ]

    "no explicit compilation / weaving required by the user as you seems to argue"

    Sorry, Alex, but I thought Glassbox Corportion (www.glassbox.com) was providing an extensible application performance management solution similiar to JXInsight which allows users to define the pointcuts (and indirectly tracepoints and trace runs) themselves which of course requires compiliation and weaving. We provide a very simple Tracer API similiar to ARM which allows users to integrate (easily) into our distributed APM agent solution.

    For every trace interval (think around advice) they can collect:
    - High Resolution Clock Time
    - CPU Time
    - GC Time
    - Thread Monitor Blocking Time
    - Thread Monitor Waiting Time
    - Clock Adjusted (very important for an APM solution)
    - Object Allocations (bytes)

    The above metrics cannot be obtained via standard Java API's today (Java5 does have high resolution clock times).

    Of course JXInsight goes much further than that because of all its distributed trace integrations which allow for a client side trace (in a Swing application) to have remote metrics across multiple JVM's as well as associated transactions (patterns, counts, clock totals, sql history, exceptions, callstacks in each visited JVM...)

    "I like the GlassBox approach for its technical value"
    I think you missed my point. AOP is just another approach to data/event collection/generation but you still need an event correlation engine and a pattern language (Book: The Power of Events). These engines can and should be built independent of the event generation system.

    AOP in this context is great at inserting (instrumenting) the event generation for applications and technologies with no existing event support.

    I am not knocking AOP but I cannot allow people say AOP => APM - leaving out an important and big step in any solution.

    "JXInsight is just one among many many many that almost pops up everyday"

    In fact I am seeing it differently. We are seeing many vendors move out of this space maybe not officially but it is happening on the ground.

    You will always get pockets of development but this is understandable because developers like creating tools for themselves irrespective of business merit. They create tools not to compete or differentiate themselves but more to educate themselves, have fun, and meet others willing to run their code on another system.

    By the way Java5 seems a bit restrictive for existing product enviroments.

    Regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  11. AOP: AspectJ, XDoclet and Tracing[ Go to top ]

    I am a little bit concerned that my previous postings may convey the wrong impression so I would like to describe a AOP success story.

    Approximately 2 years ago I finished the custom development of a tracing framework for HP OpenView that was based on our own internal API as well as ARM. This tracing framework used XDoclet for tagging classes and method for tracing with values to see the component name (not the classname) and operation (not the method name). During the build XDoclet was used to automatically generate the AspectJ aspects source code. This was then compiled with shared binary aspects/advices and finally weaved back into the bytecode of the tagged classes. Nothing really new within each step. The exciting part was the benefit to the development teams. They did not have to write trace and logging code anymore complicating the actual application logic. It was simply a matter of tagging (XDoclet) and tracing (AspectJ).

    After a while team realized that that having an useful analysis tool was required though not core to their development. Developing the tool would consume too much resources. Luckily the trace events generated by the AOP trace system could be targeted to different backends via trace event interceptors and filters.

    JInspired has implemented such a bridge between this custom AOP trace engine and JXInsight via our public Tracer API. We created an interceptor that transformed BEGIN and END trace events into calls to our Tracer. This allowed the team to obtain much more contextual information (threads, callstacks, JVM properties, transactions, class and method meta data, manifests, metrics and aggregated statistics, distributed tracing....) with little overhead. At the sametime they can use JXInsight Console to manage a distributed system with persistent snapshots and annotations/notes for team collaboration.

    Most of our trace extension are built with the same trace API (com.jinspired.jxinsight.trace.Tracer) we publish.

    Regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  12. Correlation Counts[ Go to top ]

    First off thank you for sharing so much information about your product. I am surprised you aren't more closely aligned with JBoss than Spring given the content and style contained in your several postings.

    Our approach is very different from capturing as much data as possible! We see value in integrating intelligence to collect data based on what is happening in real time. We use AOP to analyze behavior as it happens and to adapt. That's much more powerful than just capturing data as you appear to be doing.

    Using a consistent, modular implementation that has access to OO data is a dramatic improvement over traditional log and post-process architectures. I totally disagree with the should in "These engines can and should be built independent of the event generation system."

    The Glassbox Inspector supports a range of uses, from providing useful out of the box data to full programmatic customization. You can also configure it at deployment time and at runtime. Use of load time weaving supports many of these, although it's important to be configurable and to allow programmatic extension where necessary. We definitely stand on the shoulders of giants and benefit from advances in VM's and increasingly dynamic AOP implementations.

    I think production operations and QA are already drowning in a sea of data, so I question the emphasis first generation APM tools and developer tools like yours are placing on it.

    That being said, there is clear value in the capability to collect detailed accurate metrics and I'd welcome it if you would make technology like this under an appropriate open source license. Likewise for an appropriately designed bus. I believe that projects like Eclipse TPTP are too focused on raw profiling/low level data and ill suited to task...

    To your earlier post, wiring up lots of interceptors is painful, error prone, and can have surprising results because of object schizophrenia (e.g., I have seen Oracle drivers choke on proxied connections). This is an area where aspects are more flexible and effective.

    Finally, the Glassbox Inspector is an open source data collection engine. It fits into the bigger picture of products and services from the Glassbox Corporation, but we have not announced those, and I won't comment further on your speculation.
  13. Correlation Counts[ Go to top ]

    "I am surprised you aren't more closely aligned with JBoss than Spring given the content and style contained in your several postings."

    This is wonderful, making things so black and white (good and evil) about others but yet not applying the same principles to your own efforts.

    In my book a company that comes to market with an offering that is immediately announced as "open source" (a teaser) and "next generation" is making the most agressive marketing move one can do. Then to follow that up with an insult in claiming existing solutions legacy and your offering "next generation" even though I have yet to hear a single new feature that matters to an user (operations) and not a developer. Operations do not care whether it is AOP or not. Only when it works and resolves the problem efficiently does it matter.

    Seriously what kind of response did you expect. At JInspired we do not practice deception. We are a commercial entity that suppports easy product extension by developers including AOP practioners.

    "That's much more powerful than just capturing data as you appear to be doing."

    Hmmm. Does your offering today provide true resource transaction analysis like JXInsight? I can assure that when you do get around to solving this problem its very much runtime analysis and not simple logging and data collection.

    "I think production operations and QA are already drowning in a sea of data, so I question the emphasis first generation APM tools and developer tools like yours are placing on it."

    Ron, there you go again with the next generation tools stuff and yet no mention of anything of substance. We are all data collectors that only support distributed tracing (correlation), transaction analysis, indepth JVm metrics, are ability to be able to take SQL strings and parse it (unlike in your screenshots) and then provide end-to-end tracing from Swing application code line down to a datbase table and column - is this so yesteryear.

    "I believe that projects like Eclipse TPTP are too focused on raw profiling/low level data and ill suited to task..."

    I am delighted we agree on this.

    "To your earlier post, wiring up lots of interceptors is painful, error prone, and can have surprising results because of object schizophrenia (e.g., I have seen Oracle drivers choke on proxied connections). This is an area where aspects are more flexible and effective."

    It all depends. In some cases aspects are better. In others the benefits of existing infrastructure support for interceptors wins the debate.

    "Finally, the Glassbox Inspector is an open source data collection engine. It fits into the bigger picture of products and services from the Glassbox Corporation, but we have not announced those, and I won't comment further on your speculation."

    I will have to wait and see.

    William
  14. Infrared (http://infrared.sourceforge.net) is our modest attempt at building a simillar tool. We have been internally using this tool in dev & qa for more than a year now to identify performance bottlenecks. The few simple benchmarks we have run indicate that the overhead is minimal & it could be used in a production environment. We are in the process of running more benchmarks to get more confidence.

    It is based on aspectj (we use a very small subset) for capturing stats for JAVA code and P6Spy for capturing DB details. The primary mode is to use compile team weaving, a pre processing step is required to instrument the application code. We have also added aspectwerkz based LTW support.

    The metrics are available via a custom web UI (we have plans of exposing them via JMX - http://infrared.sourceforge.net/infraredroadmap.html).

    Some of the salient features are :
    1. Provides an end-to-end view, with an ability to corerelate JAVA & SQL statistics.
    2. Support for central collection. Stats from different nodes in a cluster can be collected & viewed through a single integrated UI. It also allows aggregating data from multiple nodes.
    3. Configurable to an extent. You can dymanmically configure the level of detail at which the metrics are collected. The summary mode has least overhead and can be used in a production/qa environment. The detail mode which provides the call trace add more overhead and are ideal for use in the dev mode.
    4. Web based UI.
    5. Ability to capture snapshots and analyze them at a later point in time.

    Regards,
    Kamal
    Tavant Technologies
  15. Insight Articles[ Go to top ]

    Spring AOP Tracing
    http://www.jinspired.com/products/jdbinsight/springtracing.html

    Distributed (and Disconnected) Enterprise Java Application Performance Management
    http://www.jinspired.com/products/jdbinsight/corbatracing.html

    OutOfMemoryError's Are Not Always Caused By Memory Leaks
    http://www.jinspired.com/products/jdbinsight/outofmemoryexceptions.html

    EJB 3 Tracing with Oracle OC4J EJB3 (TopLink)
    http://www.jinspired.com/products/jdbinsight/servletconfig.html

    XInsight Trace Extension for Java Servlets & JSP - Configurability
    http://www.jinspired.com/products/jdbinsight/servletconfig.html

    Graphical Excellence in J2EE™ Application Performance Management Solutions - Table Visualizations
    http://www.jinspired.com/products/jdbinsight/tablevisualizations.html

    Apache Ant and JUnit Test Case Tracing, Profiling and Transaction Analysis
    http://www.jinspired.com/products/jdbinsight/antjunittracing.html

    Client-to-Container Tracing / Profiling with JBoss Interceptors
    http://www.jinspired.com/products/jdbinsight/jbosstracing.html

    Timelines and Transactions
    http://www.jinspired.com/products/jdbinsight/concurrency.html
  16. Arghh. Please try to stay on topic and stop moving the focus. A mention of competing worldviews is ok (like Kamal did) but getting defensive and spamming the list with old articles about your product is silly.

    (Stepping down from soapbox and getting back on inspector topic)

    My basic question is "what do you want?":
    - Where does this project start and stop and what is still needed?
    - It's loadtime and doesn't focus on oodles of data collectors and logs, so does that mean you don't need more collectors written or just that it's not your focus?
    - You're looking for help in writing analysis?
    - Writing reporting on top?

    W

    <If this is a repost, I apologize, the first one didn't seem to take so I had to re-write it>
  17. We welcome contributions[ Go to top ]

    Hi Wendy,

    We are just getting started and see tremendous opportunity to build an open source solution by the community and for the community. We are interested in feedback and contributions from others who would like to build a great performance management solution. We would welcome contributions along the full range from deeper metrics, capturing data from standard APIs of data, better correlation and ways of analyzing and reporting. From the project's Web page, some of the many exciting future extensions are:

    • Capturing more context about what’s happening (e.g., stack traces and parameters), especially for unusual results (failures or abnormal response times)
      Monitoring top-level resource information (e.g., total database time)
      Monitoring more operations, resources such as JMS and EJB, and expanding coverage for CPU-intensive components such as XML processing
      Using Java 5 management information such as CPU times
      Capturing history and trends, with persistent storage and reports
      Using JMX to provide alerts and exposing statistical summaries
      Allowing sampling to vary the amount of data captured
      Monitoring system events, such as 404 errors for requests to an Web application that aren’t bound to a Servlet
      Monitoring business events, such as customer purchases or abandoned shopping carts
  • Ok,

    All good and well but am i correct in seeing that the jxinsight uses a native trace library ? I believe the Glassbox aproach is platform neutral ? or not ?

    I really need a solution along these lines for performance and tracing on both websphere on the windows platform and websphere on SUN SOLARIS. Now I have to deal with websphere 5.0.x so IBM JRE 1.3 unfortunately. From what I have read so far on both its difficult to get this going or does anybody have another suggestion here ?

    Greetz
    Leo de Blaauw
  • Hi Leo,

    JXInsight is part native (JVMPI, c agent) and part Java. Our native agent is supported on many platforms including Windows, Linux, Solaris, AIX, HP-UX, and OSX.

    It would be impossible to have a performance management solution that has minimal overhead while sufficient levels of metrics and context without native JVM integration. Callstacks are incredibly slow to obtain in 1.3 and 1.4. There is no possibility of getting GC and thread monitor metrics without going native.

    I am aware of one issue with the IBM 1.3 JRE JIT where it throws a NullPointer exception in a method in our JDBC driver ResultSet class because it incorrectly interprets the bytecode (try-catch-finally) generated by Jikes.

    I am not sure that this JRE problem occurs on all OS platforms. I have seen it on Windows though I am not sure it still exists. A solution we offer customers is a build of our library with the Sun javac of course you can always switch off JIT or use an alternative JRE for testing.


    Kind regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  • good to know ![ Go to top ]

    Hi Leo,JXInsight is part native (JVMPI, c agent) and part Java. Our native agent is supported on many platforms including Windows, Linux, Solaris, AIX, HP-UX, and OSX.It would be impossible to have a performance management solution that has minimal overhead while sufficient levels of metrics and context without native JVM integration. Callstacks are incredibly slow to obtain in 1.3 and 1.4. There is no possibility of getting GC and thread monitor metrics without going native.I am aware of one issue with the IBM 1.3 JRE JIT where it throws a NullPointer exception in a method in our JDBC driver ResultSet class because it incorrectly interprets the bytecode (try-catch-finally) generated by Jikes. I am not sure that this JRE problem occurs on all OS platforms. I have seen it on Windows though I am not sure it still exists. A solution we offer customers is a build of our library with the Sun javac of course you can always switch off JIT or use an alternative JRE for testing.Kind regards,William LouthJXInsight Product ArchitectJInspired"J*EE tuning, testing and tracing with JXInsight"http://www.jinspired.com


    Yeah i have been trough many hoops and hurdles with IBM JRE's in my JAVA life......

    I asked trough your company support department for the same questions. I also tried getting a download link but havent gotten a reply as of yet. I would sure like to test on our setup if we can get it all to work. If we do it would help us and the client in a big big way.

    Greetz
    Leo
  • JRE's and JXInsight Installer[ Go to top ]

    Hi Leo,

    I can tell you that all JVM's break your heart. Its best to not to get too friendly with them. We use a very small subset of JVMPI and soon JVMTI.

    We are just about to upload JXInsight 4.0 RC4 with some ease of use enhancements around classloaders and extensions for IBM WAS. We had hoped to already get back to you sooner but the testing ran over a little. Apologies. Email shortly.

    William
  • Hi Leo,

    There is an IBM Classloader plugin API that I am actively investigating using with AspectJ load time weaving, that would be the most natural way to plug in to a WebSphere environment.

    Alex Vasseur has also written a blog entry on means of using AspectJ 5 load-time weaving on older VM's. See http://blogs.codehaus.org/people/avasseur/archives/001140_aspectj_5_load_time_weaving_with_java_13_using_aspectwerkz.html

    Note that we are focus on portable, low overhead capturing of key statistics but are not trying to provide profiler-levels of detail. This makes integrating portability easier.
  • Hi Ron,

    Yeah definitely would be interested in the aspectj load time weaving on WAS... I browsed trough the article by alex vasseur but havent had time to test it yet....

    Obviously before there is a WAS version with JRE (IBM's) 1.5 and a client actually using it we are two years out from now... ;-)

    Leo
  • Hi Leo,

    I wanted to let you and any other interested parties know that I have submitted a load-time weaving plugin contribution for AspectJ 5. You can read about it at http://rbodkin.blogs.com/ron_bodkins_blog/2005/10/websphere_loadt.html You can also download a jar and read basic instructions on installation from the Aspectj bug report containing the contribution at https colon slash slah bugs.eclipse.org/bugs/show_bug.cgi?id=111027 ).

    We expect to integrate this into the next release of the inspector too.
  • Ron - "Note that we are focus on portable, low overhead capturing of key statistics but are not trying to provide profiler-levels of detail. This makes integrating portability easier."

    High level statistics, with little trace contextual information, just category aggregation, are only useful in production systems where software change (applications, appserver config) is controlled and the focus is on detecting what external changes have occurred in the environment (network, database, messaging, hardware) via comparison with previous measurements. The statistics should pinpoint which external resource is behaving differently assuming the workload placed in the resource is the consistent with previous measurements.

    Unfortunately this is not the case in the real world. A large proportion of applications are deployed into production systems with insufficient performance testing and risk assessment of the software changes especially under concurrent variable workloads. Here the art in performance engineering is understanding the execution behavior (tracing and profiling) characteristics of the software itself. High level statistics might point to difference but they will not help in problem resolution which requires narrowing the scope down from a system level to a component/resource level.

    The following article might help you understand this better.
    http://www.jinspired.com/products/jdbinsight/concurrency.html

    I have yet to see a customer resolve an application software change via JMX statistical measurements. In fact if you look at the companies in this industry you would see that they are moving away from mere reporting to indepth tracing and low level metric data collection and analysis.

    By the way JXInsight has been designed for all phases of the application life cycle (developing, component testing, system testing and production). That is why we provide many perspectives (profile, timeline, metrics, transactions, SQL, application configuration, resources, system properties, classes/classloaders, exceptions, calls, traces) on application performance management.

    Portability at the implementation level is different than protability at the product level. Customers care little about how you minimise your own development costs as long as the product at the user level delivers the same feature set with similar execution characteristics and costs. By the way C is very portable - most JVM's are written in C.

    By the way in JXInsight 4.5 which we are just starting to develop we have introduced IntelliJ like Inspections of the traced application execution behavior which does not require real-time analysis.

    Regards,


    William Louth
    JXInsight Product Architect
    CTO, JInspired

    "J*EE tuning, testing, and tracing with JXInsight"
    http://www.jinspired.com