Comment on page
About processors
Processors form the core of the Joule platform. A processor performs a distinct unique function when chained with others form a business use case
Processors when chained together form a use case, known as a pipeline. Events are processed in sequence with final events either being presented to the select processor or connected transports.
Processors can be categoristed in to various functional grouping that reflect there purpose within the platform
- Filtering
- Enrichment
- Transformation
- Activiation based
- Analytical
Joule has provided a number of core features for developers to build off of for custom use case components
Every processor that inherits from the base class
AbstractProcessor , using the Joule SDK, will gain these core features.Attribute | Description | Data Type | Required |
|---|---|---|---|
name | Uniquie name of processor. | String Default: Random UUID | |
enabled | Toogle to enable processor processing | Boolean Default: true | |
properties | Processor specific properties | Map | |
clone event | Toogle to clone event for processing. Note this will cause significant memory overhead for high load use cases | Boolean Default: false | |
stores | External data stores can be attached, useful for analytics, enrichment, filtering and transformation use cases | | |
latency trigger | Number of events processed to trigger the average processing calculation. A value less than 1 switches off the calculation. | Integer Default: 1000 |
Each OOTB processor record and presents event metrics to JMX monitoring platforms. This provides direct insight into how a streaming use case is performing.
Metrics available
- Received
- Processed
- Failed
- Discarded
- Ignored
- Average processing latency
All of these metrics are enabled by default and presented as JMX beans on the standard monitoring ports.
Apply these settings to the joule execution path
-Dcom.sun.management.jmxremote.port=5000
-Dcom.sun.management.jmxremote.rmi.port=5000
Last modified 2mo ago