Technical Elements and Interoperability - SiteStats Dry Run

Owned by Former user (Deleted)
Last updated: Nov 13, 2009Version comment
4 min read

General Technical:

  • What kind of project is this?
    SiteStats is a new tool, built from ground up. It registers for notifications with the Sakai Event Tracking Service for site related events generated by tools in site, and persists aggregated values to hibernate managed tables.
  • What level of code review has been applied?
    By the time the tool reached the 2.0 version, SiteStats was analysed by Alan Berg's Automated Code review scripts and reviewed toghether. Since then, some manual review is made from time to time using PMD, Firebugs and Sonar. The tool maven configuration has goals to generate PMD and FindBugs analysis and, locally, it is periodically analysed with Sonar.
  • What architectural or technical documentation exists?
    Sakai wiki page for the project including installation and configuration guides, and performance considerations
    JIRA has been used to track all tasks and bugs from release 0.2 onwards
  • How many people have been working through the code?
    Mainly, Nuno Fernandes, Feliz Gouveia (Universidade Fernando Pessoa) and David Roldan Martinez (Universidade Politecnica de Valencia). There are some others sporadic contributors, though.
  • What is the lifetime of the code? How long has this code been around?
    The first development versions of the tool were on a local svn repository. Since version 0.2 that SiteStats is hosted on Sakai SVN Contrib repository (March 2006).
  • How long and where has been it in production?
    Universidade Fernando Pessoa has been running SiteStats in production since the 0.1 pre-release (early 2006), followed by UCT (University of Cape Town) on the same year. Since then, many others institutions have been running the tool in production (UNISA, Universidad Politécnica de Valencia (UPV), Indiana University (IU), University of Colombia, Claremont Colleges, University of Windsor, Georgia Tech, University of Hawaii, possibily others).
  • Is the project planning on independent releases?
    Current stable releases (2.0.x) are available on Sakai's contrib subversion repository. Anthony White has recently configured the tool for independent releases on binary format available from Maven repository (2.1-SNAPSHOT).
  • What happens if an instance uses, then uninstalls the project?
    The project is a simple add-on which can be safely installed and unninstalled (by simply removing the deployed jars/wars from the application server). If an institution decides to re-install the tool, there is the possibility to aggregate all missing event data (from the period the tool was uninstalled) through the provided Quartz Job.

Code Maintenance / Metrics:

  • How large is the project? (Lines of code / modules)

    Module

    Lines of Code

    Comments

    Methods

    Classes

    Packages

    API

    1373

    629

    286

    33

    5

    Impl

    10328

    1079

    446

    41

    6

    Impl-Hib

    526

    201

    27

    7

    1

    Tool

    7754

    563

    690

    74

    7

    TOTAL:

    19981

    2472

    1449

    155

    19

    Source: Sonar 1.11.1
  • How many non-kernel Sakai dependencies?
    Scheduller (Quartz job), SakaiMock (tests)
  • How many non-Sakai dependencies?
    Apache Wicket
    Apache Wicket Extensions
    Apache Wicket Spring
    Apache Wicket Spring Annotations
    Apache Wicket DateTime
    Apache Commons Digester
    Apache Commons Betwixt
    Apache Commons BeanUtils
    Apache Commons Lang
    Apache XMLGraphics
    Apache POI
    JFreeChart
    Log4J
    SLF4J

All available from Maven repositories.

  • Are there core dependencies on libraries not typically used in Sakai?
    Mainly Apache Wicket and JFreeChart (although the first is becoming more popular in Sakai development).
  • How tightly coupled is your tool with non-Sakai dependencies?
    The above dependencies are essential.
  • What is the persistence mechanism?
    All database objects are managed by Hibernate.
  • Any known JVM version dependencies preventing or forcing a Java 6 or Tomcat 6 upgrade?
    The tool is known to work nicely on Java 5 and Tomcat 5. Tests with Tomcat 6 + Java 5/6 will me made soon.
  • Are there automated tests?
    Currently, there are automated tests for the most important services on the Implementation module. Additional services will be covered in future releases.
  • Is the documentation up to date with the tool?
    Yes - the SiteStats Conluence page is always updated when required right after its commit it in trunk. See Confluence http://confluence.sakaiproject.org/display/STAT. Additionally, there is end-user documentation in the form of a help bundle for the Sakai Help tool.
  • Are there kernel changes required to support the project?
    No.

Production Setup / Maintenance:

  • Are there any conversions, migrations or other administrative preparations required in order to start using the tool?
    No.
  • Is there required configuration or does it work out of the box?
    All the configuration settings are optional and the tool is ready to work out of the box.
  • Can complex or objectionable features be disabled?
    All configurable in sakai.properties. The tool Confluence page has a dedicated page with all configuration details.
  • Does this tool depend on a file storage mechanism other than Content Hosting?
    No.
  • Are there any special requirements for deploying this project in a cluster? For example, does this project assume JGroups, shared network storage, UDP multicasting, or Terracotta server.
    No. It has been verified as working OK on a cluster environment - actually, we (UFP) run it in a cluster.
  • Was load testing performed? What were the results? Is a load testing report available?
    I had performed some load testing for code optimization a long time ago on the 1.x versions - however, I currently don't have any useful information about it. David Roldan Martinez had also run some load tests with SiteStats right afterwards which revealed some performance increase.
    It would be excellent (and desirable) if the tool could have some kind of automatic load testing procedures (fired my Maven?) in the future.
  • Are there features that are database intensive, either in terms of large data or heavy CPU demand?
    The event aggregation mechanism needs to update value on SiteStats tables which can be, in some configurations, some what heavy. There are two operational behaviors options regarding this: a real-time event aggregation thread (for small-medium sized installations) and a quartz job for event aggregation to be scheduled at will (for large sized installations).

Interoperability:

  • Does any other Sakai tool or service depend on this functionality?
    Not that I am aware of. There is currently (since Sakai 2.6.0) an Entity Broker capability that allows tools to self-register with sitestats, optionally providing event translations - this is made with a dependency on Entity Broker and none on SiteStats.
  • Are there overlaps in functionality with other tools or services?
    No.
  • Is content created within sites? If so, are archive, import, search and duplicate features implemented?
    Since version 2.0 there are per site reports. This data that can be imported/exported between sites. Archive is not implemented yet. Duplicate feature is available within the tool.
  • Are there any data feeds (RSS, XML, JSON) exposed via the Entity broker, sdata, or a one-off implementation?
    Currently not, but it is something that will implemented in the future.
  • Does the work implement particular notable standards?
    No.