As a system maintainer, I want to instrument Smooks in order to create alerts on failures, gain performance insights, and so on. In particular, I want to know which nodes are being visited, how many visits have failed, the average processing time of executions or visits, the stream sizes, etc...
At present,
org.smooks.engine.report.HtmlReportGenerator is the de-facto way for obtaining some visibility into the Smooks runtime. Besides being inefficient and not designed for production-use, HtmlReportGenertor only offers a very limited view into Smooks. We should (1) broaden this view to include other data like performance indicators while (2) making it easy for developers to add their own metrics. At the same time, we should (3) reduce the plumbing required in order to make it easy for operations to lift the instrumentation data off Smooks.
I propose that we instrument a no. of important Smooks objects with JMX.The most important ones that come to my mind are visitors, the execution context, and the application context. Instrumenting the execution and application contexts should be relatively straightforward. We can write a Smooks resource that registers these objects with an MBean server after dependency injection (i.e., @PostConstruct). Which exact attributes the MBean server should manage is up for debate but we should solicit input from the community.
Instrumenting visitors to efficiently collect metrics like the total visit time might be a little trickier, but with the introduction of interceptors in v2.0.0-M2, I think it's mostly a matter of putting the calculation logic in a new interceptor that is managed by the MBean server. We could even use this interceptor to send JMX notifications indicating the events that were visited. It goes without saying that all this instrumentation should be part of the benchmark suite that we run on every push.
Claude