Kamanja v1.4 – released May 4, 2016

Release Notes for Kamanja 1.4

These release notes refer to an old version of Kamanja. We have retained them for reference, but disabled the links. Please click on the 'Download' link on this site for the most recent version of Kamanja, and contact us if you've any queries. Thank you!

This major release introduced the most new features ever released at one time in Kamanja history! The features are categorized in several main themes:

  • Ease of Use
    • No Shutdown Changes (Configuration Only) - no need to shut down the engine if there are adapter configuration changes!
    • New Sample Models and Tutorials
      • Creating a Simple Model in R and Consuming It in Kamanja
      • Putting a R/Rattle Model into Production using Kamanja
      • Tutorial for Building a Simple Model Ensemble. 
    • Reduced Package Size - package size reduced during the compilation of Kamanja. Things will go much faster now!
    • Support for Metadata Backward Compatibility - migration time reduced by making metadata backward-compatible. Migration time speeds up!
    • Tool for JSON File Validation - tool called JsonChecker provided to validate any given JSON file including the configuration file. This tool checks whether the JSON file contains a valid JSON.
    • Adapter Interface Changes - more control for adapters. More changes can be made to the adapters to make them more extensible!
  • Administration
    • Basic Multi-tenancy - Process and Client Isolation - Kamanja now has basic multi-tenancy. Each business unit or division is known as a tenant or use case. So, for example, if a company has two use cases, both use cases can be deployed on the same cluster. To handle this, the engine has to balance how much processing time to give each use case. Each tenant has its own input adapter, output adapter, and storage adapter, as well as default storage. All this allows multiple use cases on the same cluster!
    • Message-level Tracking - event-level information traced to a destination that is specified in the cluster configuration file. The information is in JSON string format. The JSON string describes message-level events such as which message got executed, when was it executed, and which models were executed.
    • Failure Notification as a Message - internal message generated and the engine automatically writes it into an adapter specified in the cluster configuration file.
    • Additional APIs to Expose Monitoring Data - three new methods to monitor Kamanja. The new methods are getHealthCheckNodesOnly, getHealthCheckComponentNames, and
      getHealthCheckComponentDetailsByNames.
    • Tool to Purge Container Data - tool called ContainersUtility designed to help select, delete, and truncate data from a container using a key and/or timerange.
  • Model Support
    • New Message Structure and Unification - new message definition defined and it exposes the message API. Note: In Kamanja v1.4, in the message definition file, Persist must be set to TRUE. PartitionKey must also be set to save data in the data store.
    • Transformations - Beta version - Kamanja engine now ingests JSON Transformation Models (JTMs)! A JTM is another kind of model that is principally dedicated to simple data transformations.
    • Data formats (CSV, JSON) - serialization encodings built into Kamanja and available for adapter use by simply referencing their names in the adapter configuration - kBinary, CSV, and JSON.
    • Execution DAG - Kamanja implements an execution DAG, in order to reduce the time it takes for a packet of data to get from one point to another, which is a very efficient model for scheduling work. A Tutorial for Building a Simple Model Ensemble was also created.
  • Adapters
    • Serialization and Message Bindings - binding added that is composed of a message, its origin (or destination), and an encoding (JSON, CSV, et al). The plan is to catalog the encoding (the serialized/deserialized object to use), and then to reference it in the cataloged binding that refers to the origin/destination (source/sink) and message. By having bindings, static binding is enabled at registration time and this gives more control at model registration time and speeds up the runtime!
    • Smart File Input Adapter - users provided with the ability to automatically add new files to the Kamanja server from specified folders.
  • Model Management
    • Model Association to Events/Messages - static bindings added at registration time rather than dynamic binding at runtime that occurred in previous releases. What messages a particular model can process is defined and the messages the engine can output are specified. This change in the model interface results in better optimization and faster processing. There are expanded commands for kPMML and PMML, and new changes for the model configuration file for Java/Scala models (model configuration changes).