Website and other public(ity) stuff

Sensor is just in the process of moving from Age's personal playground project to a more public project where multiple people can provide input or code. This obviously means the project needs a public website and all the supporting stuff around it so people can work together.

• Get the (this) website up at http://sensor.sf.net/ ASAP !!!
• Get a logo
• Get our own open source Clover license instead of the 30-day evaluation license used at the moment. (thanks Cenqua !)
• Get a JIRA instance
• Get a Confluence instance
• Host a maven repository on the sf web (is this allowed ?)
• Reboot the mailing list and add everyone who has shown interest since the project re-start

Core, Types of Sensors

The sensor core is where the actual sensors and their runtime accessors are defined and implemented. It should (eventually) be very stable and it serves as the main API for sensor.

• Should there be a generic Sensor interface implemented by all types of sensor. This would not work for at all Gauges and it would be problematic for counters...
• Should Meters and Gauges (and Counters) be merged or not ?
• Add standard deviation and first/last time support to Timers
• Investigate the addition of a thread-bound event system as described by Lars. This would give people an idea of the flow of events during
• OR add a full event system to ALL sensors, allowing other components to listen to events and perform the same type of reproting as described in the above idea by Lars.
• Notification (email, ?) based on configurable threshhold values could be hooked into an event-based system
• Add an implementation inbetween static and dependency injected for situations where there is a need to combine static and non-static runtimes (like when you have a basic non-static setup for most of the application but there is a small piece of code (a session listener for instance ?) that does not have immediate access to the non-static runtime.

Integrating sensors into applications (was: AOP)

Sensor obviously needs to be applied to all types of existing applications. Using AOP techniques like Spring interceptors or full AspectJ seems to be the obvious and most powerful way of integrating sensors into an existing application. But we should be careful not to make this choice mandatory by basing our implementations solely on Aspects. That is IMHO a mistake that other tools like Glassbox Inspector and Infrared have made, limiting the use of their tools to situations where the use of AspectJ is possible. Since lots of big customers are still quite afraid of AspectJ, this should be a choice. Hardcoded application of sensors to source code should be discouraged but it should not be impossible.

• Rename the sensor-aop module to sensor-integration ?
• Should integration support be seperated from pure AspectJ support ? They are quite different. We could simply start a sensor-aspectj module...
• Add timing, counting servlet filters (always in static and dependency injected form !)
• Added session counting session listeners (always in static and dependency injected form !)
• Add abstract AspectJ aspects that only need a valid pointcut definition

Remoting

The idea is to have the sensor core plus remoting running on VM A so that all persistence and reporting functionality (see below) can run on VM B. This would lower the overhead on the VM being monitored. The obvious implementation candidate would be Spring remoting but the choice or protocol would be slightly harder... a REST webservice ? Binary data ?

• What about non-spring apps ? How to support remoting on them without requiring the full Spring dependency stack ?

Periodic Persistence

This involves code that periodically takes a snapshot of the current statistics and writes that snapshot to a persistent store. Such a store could be implemented by:

• A database
• A file (XML, binary, both ?)
• A simple log(4j) file

• Where to put the code that calculates the difference between two statistics snapshots ? Not in Statistics, which is bound to the internal storage. This should probably be done by a PersistenceService that maintains the last snapshot and a Statistics instance and can perform a (refreshed statistics minus last snapshot = new snapshot) operation.

Reporting

• The user interface for showing timer call trees should be dynamic and could use ajax to retrieve nested statistics. Implement a straightforward version first and build an ajax enabled version later !!
• Allow sorting on all fields. This means we need some standard comparators.
• Implement filtering wrappers that can filter on any field or combination of fields. So we can say "only show timers with a label containing 'dao" and an average time greater than 30 ms". The web interface for this should be intuitive and look something like the outlook "sliding from the top" search panel with the label field enabled by default and the rest dynamicly addable.