Petals Documentation > Petals ESB > Petals Components > Components User Guide > Petals-SE-XSLT > Petals-SE-XSLT 2.10.0+

Petals-SE-XSLT 2.10.0+

This version must be installed on [Petals ESB 5.3.0]+

Features

The XSLT Service-Engine allows to transform Petals messages using XSL style sheets.

Each configuration of this component embeds an XSL style sheet.
When such a configuration (i.e. service, i.e. service-unit) is called, it transforms the received message into another one.
The XML payload of the input message is transformed using the XSL style sheet.
The resulting XML document is then returned in the response, either as the payload, or as an attachment.

This component only acts as service provider, not as a service consumer.
In fact, it provides a transformation service.

Additional information about XSLT can be found at http://www.w3.org/TR/xslt.

XSLT Component overview

Recommended usage

The XSLT component should be used when chaining calls to services whose output and input do not match.
It can also be used to expose XSL transformations as a service, provided that the content to transform is passed in the message payload, and not as attachment.

Taking an example

Let's take the example of two "white pages" services.
These services aims at helping in finding where a person lives (or how to contact this person).

First, you want to call the operation lookup of a service "White Pages".
This operation takes the first name and the family name of a person, and returns a list of phone numbers.
Each phone number is given as a string.

Its prototype looks like

lookup( String firstName, String familyName ) --> String[] phoneNumbers

Do not forget this prototype would be in fact described in the WSDL interface of the service (under an XML shape).

Then, you want to call a service that finds a geographical area (e.g. a city) from a phone prefix.
It is the operation resolve from a service "PrefixToAreaLocalizer".
From a phone prefix, it returns a geographical area.

Its prototype looks like

resolve( int phonePrefix ) --> String areaName

Once again, this prototype is described in the WSDL interface of this second service.

To chain these calls, you have to transform the output of the operation lookup to match the input of the operation resolve.
Indeed, you cannot directly execute

resolve( lookup( "Pierre", "Paul"));

What you will do in your XSL style sheet is extracting the phone prefix from a phone number.
The list go-through will most likely not be made in the XSLT transformation.

There is no more simple way to make the transformation.
In Petals, as well as in most of SOA-related technologies, messages are XML messages.
And for every service, the operations, with their in and out parameters, are described in their WSDL interface.
So, the output message of the resolve operation is an XML (SOAP) message, and the input message of resolve operation is an XML message too.
These XML messages must match the WSDL descriptions of these services.

Obviously, this example is extremely simple.
But the usage remains the same, even with complex XML structures.

XSLT and chaining services

Following our previous example, it appears that chaining and transforming service calls implies using a chaining service (some could say an orchestration service).
This chaining service would do the following calls:

  1. Message from the chaining service to a first service.
  2. Response from the first service to the chaining service (we assume the first service works in InOut message exchange pattern).
  3. Message from the chaining service to the XSLT service.
  4. Response from the XSLT service to the chaining service (the MEP is InOut, always).
  5. Message from the chaining service to a second service. The transformed message is sent to it.
  6. Optional response, depending on the MEP for the second service.

This chaining service can be implemented by a POJO (an home made Java Class) or an Enterprise Integration Pattern (EIP).
It could also be implemented by a BPEL process, but in fact, that would not be a great idea.
BPEL supports the extraction of data from XML messages during the orchestration. When you have a BPEL process, you do not need XSLT. You can use XPath expressions and functions directly in the BPEL. Besides, working with BPEL would require the XSLT configuration to have a WSDL interface while they do not always have one.

Limitations and warnings

The transformed content is always the payload from the input message.
Do not mistake XSLT services for interceptors.

A XSL transformation service cannot transform messages addressed to another service.
Neither to transform attachments, nor to intercept messages on the fly. An orchestration service is required to make the link.
Interceptors would better fit this kind of use case.

To work with XSL style sheets of more than 1000 lines, you have to use another engine than the default one shipped with Java (Xalan 2.6.0 for Java 6 for Petals <5 and Xalan 2.7.0 for Java 7 for Petals >5).

This is due to a bug of Xalan of versions previous than 2.7.1. To bypass it, you have to use a newer version of Xalan (2.7.1 +) or another XSLT engine using a Shared-Library.
Note that for version 2.5 up to 2.7, Saxon is the default engine, so the problem does not arise.
Table of contents
Contributors
No contributors found for: authors on selected page(s)

Creating a XSL Transformation service (Provides modes)

Each XSLT service runs on the Petals XSLT component.
The Petals XSLT component has native operations to invoke. These operations are inherited by the XSLT services.
A XSLT service cannot add additional operations. It only has the ones of the XSLT component.

The version 2.5 of the Petals XSLT component exposes two operations.

  • transform: the received message is transformed with the XSL style sheet. The transformation result is returned as the response payload.
  • transformToMtomAttachment: the received message is transformed with the XSL style sheet. The transformation result is attached to the response in MTOM mode.

The "transform" operation

The fully qualified name of this operation is:

  • Name space URI: any URI, provided it is not null (e.g. http://petals.ow2.org/components/xslt/version-2)
  • Local part: transform

This operation only supports the InOut message exchange pattern (MEP).
When invoking this operation, you must call it using its fully qualified name.
It must also be the operation name in the WSDL of any XSLT service.

Here is the execution flow for this operation:

  1. The received message is transformed with the XSL style sheet.
  2. The transformation result is returned as the response payload.

The result of the transformation depends on the XSL style sheet.

If an error occurs during the transformation, then a fault is raised.

<?xml version="1.0" encoding="UTF-8"?>
<xsltFault xmlns="the name space of the invoked operation">
    <message>An error message</message>
    <details>A stack trace (optional)</details>
</xsltFault>
Don't forget to enable the attachment forward (forward-attachments) when transforming an incoming request containing MTOM reference.

The "transformToMtomAttachment" operation

The fully qualified name of this operation is:

  • Name space URI: any URI, provided it is not null (e.g. http://petals.ow2.org/components/xslt/version-2)
  • Local part: transformToMtomAttachment

This operation only supports the InOut message exchange pattern (MEP).
When invoking this operation, you must call it using its fully qualified name.
This operation cannot be described in a WSDL, because of the result it returns.

Here is the execution flow for this operation:

  1. The received message is transformed with the XSL style sheet.
  2. The transformation result is attached to the response in MTOM mode.

The attachment is not sent in MTOM mode.
The result of the transformation has always the same shape.

<attachedTransformResponse xmlns="..." xmlns:xop="http://www.w3.org/2004/08/xop/include">
    <fileContent>
        <xop:include href="cid:attachmentName" />
    </fileContent>
<attachedTransformResponse>

... where attachmentName is the name of the attachment (as specified in the service-unit, or a default value otherwise).

If an error occurs during the transformation, then a fault is raised.

<?xml version="1.0" encoding="UTF-8"?>
<xsltFault xmlns="the name space of the invoked operation">
    <message>An error message</message>
    <details>A stack trace (optional)</details>
</xsltFault>

XSL parameters

XSL style sheets supports the definition of parameters.
These parameters can be passed dynamically when executing it.

You can find additional information about it on these web sites:

The Petals XSLT component allows you to set XSL parameters in two different ways:

  • The first one is a static definition in the jbi.xml.
    • It allows you to reuse a same XSL style sheet in several services.
    • Take a look at the jbi.xml parameters for more information.
  • The second way is by setting them at runtime, in the message properties.
    • Please, understand that this is not the message payload that defines the parameter values.
    • It is the properties of the incoming Petals service (called an exchange). For more details, see Exchange#setInMessageProperty( String, Object ).

Static parameter values may be overriden by dynamic ones.
But only if the static values were defines as overridable.
Trying to override a parameter value that is not overridable will result in a fault.

Remember, XSL parameters are declared with a param element in the XSL style-sheet.
A XSL parameter can be global (declared as a root element) or local (declared inside a template).
The value of a XSL parameter can be retrieved with $parameter_name or {$parameter_name}, depending on the parameter usage.

XSLT transformer processor

The Petals XSLT component enables you to choose the XSLT processor.

By default, Xalan 2.7.0 (shipped with Java 7) is used as the default XSLT engine. It is possible to select another XSLT processor for a specific SU than the default one by:

To set the shared library to use into the Petals XSLT component, use the Petals maven plugin.

XSLT efficiency

A pool of XSL transformers is created for each SU at its start in order to obtain better performance. Two parameters enable you to set the number of XSL transformers to create at the start of the SU and the maximum number of transformers to instantiate. If all the XSL transformers are used (because of receiving a lot of requests concurrently on the service), the request blocks until a transformer is released.

WSDL definitions

It is recommended to define a WSDL definition which describes the transform and "transformToMtomAttachment" operations.

The input and output messages for the transform operation are related to the XSL style sheet.
In fact, the input message should be the output message of the previous chained service (the one whose output must be transformed).
And the output message should be the input message of the next chained service.

The input message for the transformToMtomAttachment operation is related to the XSL style sheet.
In fact, the input message should be the output message of the previous chained service (the one whose output must be transformed). The WSDL message should reference a XML element of the same type than the input message of the transform operation.
And the output message should describe the MTOM structure that was documented above. In this structure, fileContent is a base64Binary element and the xop:include element does not appear.

As said at the beginning of this section, WSDL are not mandatory though. Typically, integration use cases do not require one. But not having one is bad practice in SOA.
Your XSLT service is then not reusable, and no one else will ever use it unless you give him the XSL style sheet to determine the expected input and output.

Beginning by creating a WSDL, and then continuing by the XSL style sheet appears as the best practice to have.

Service Unit Configuration

All needed information must be defined in the service-unit JBI descriptor. This JBI descriptor is configured through parameters divided in following groups:

  • JBI parameters that defines the service provider identification,
  • CDK parameters that are parameters driving the service provider implementation at CDK layer,
  • CDK interceptor parameters that are parameters driving interceptors at CDK layer,
  • Dedicated parameters that are parameters driving the service provider implementation at component layer.

CDK parameters defining service provider implementation

The following parameters correspond to the CDK configuration of the service provider implementation.

The service provider is defined into the section 'provides' of the JBI descriptor, containing:

Parameter
Description
Default
Required
Support placeholders
interface-name
 Interface name of the service provider. Must match the one defined in the WSDL.
-
Yes
No
service-name
 Service name of the service provider. Must match the one defined in the WSDL.
-
Yes
No
endpoint-name
 Endpoint name of the service provider. Must match the one defined in the WSDL. The value 'autogenerate' will force Petals ESB to generate an endpoint name as UUID at deployment time.
-
Yes
No
timeout
 Timeout in milliseconds of a synchronous send. This parameter is used by the method sendSync(Exchange exchange) proposes by the CDK Listeners classes.
Set it to 0 for an infinite timeout.
30000
No
Yes
su-interceptors
 Service unit interceptor configuration. See Service unit interceptor configuration.
-
No
No
exchange-properties
 This sections defines the list of properties to set to the JBI exchange when processing a service.
-
No
No
message-properties
 This sections defines the list of properties to set to the JBI message when processing a service.
-
No
No
validate-wsdl
 Activate the validation of the WSDL when deploying a service unit.
true
No
No
forward-security-subject
 Defines if the security subject will be forwarded from IN message to OUT message.
false
No
No
forward-message-properties
 Defines if the message properties will be forwarded from IN message to OUT message.
false
No
No
forward-attachments
 Defines if attachment will be forwarded from IN message to OUT message.
false
No
No
activate-flow-tracing
 Enable ('true') or disable ('false') the flow tracing for this service provider. This value overrides the value defined at component level and can be overridden at incoming exchange level.
Value defined at component
No
Yes
wsdl
 Path to the WSDL document describing services and operations exposed by the provided JBI endpoints defined in the SU.
The value of this parameter is :
  • an URL
  • a file relative to the root of the SU package
    If not specified, a basic WSDL description is automatically provided by the CDK.
-
Yes
No

CDK parameters driving interceptors

The following parameters drive interceptors at CDK layer.

Interceptors can be defined to inject some post or pre-processing in the service provider processing or service consumer processing.

Using interceptor is very sensitive and must be manipulated only by power users. A non properly coded interceptor engaged in a component can lead to uncontrolled behaviors, out of the standard process.

Example of an interceptor configuration:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi xmlns:jbi="http://java.sun.com/xml/ns/jbi" xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5">
   <jbi:services>
      <jbi:provides|consumes>
         <!--...-->
         <petalsCDK:su-interceptors>
            <petalsCDK:send>
               <petalsCDK:interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
                  <petalsCDK:param name="myParamName2">myParamValue2</petalsCDK:param>
               </petalsCDK:interceptor>
            </petalsCDK:send>
            <petalsCDK:accept>
               <petalsCDK:interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
               </petalsCDK:interceptor>
            </petalsCDK:accept>
            <petalsCDK:send-response>
               <petalsCDK:Interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
               </petalsCDK:Interceptor>
            </petalsCDK:send-response>
            <petalsCDK:accept-response>
               <petalsCDK:Interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
               </petalsCDK:Interceptor>
            </petalsCDK:accept-response>
         </petalsCDK:su-interceptors>
         <!--...-->
      </jbi:provides|consumes>
      <!--...-->
   </jbi:services>
</jbi:jbi>

Interceptors configuration for SU (CDK)

Parameter Description Default Required
send Interceptor dedicated to send phase, for an exchange sent by a consumer - No
accept Interceptor dedicated to receive phase, for an exchange received by a provider - No
send-response Interceptor dedicated to send phase, for an exchange (a response) received by a consumer - No
accept-response Interceptor dedicated to receive phase, for an exchange sent (a response) by a provider - No
interceptor - name Logical name of the interceptor instance defined at component level, see CDK Component Interceptor configuration. - Yes
param[] - name The name of the parameter to use for the interceptor for this SU - No
param[] The value of the parameter to use for the interceptor for this SU - No

Dedicated configuration

The following parameters correspond to the component specific configuration of the service provider implementation.

Parameter Description Default Required
stylesheet The relative file path of the XSL style sheet in the service-unit
-
Yes
output-attachment-name The attachment name to use when the transformToMtomAttachment operations is invoked
-
No
xsl-parameters A list of xsl-parameter elements
-
No
xslt-engine-factory-class-name The XSL transformer factory classname
-
No
xslt-engine-pool-size-min The number of XSL transformers to create at the start of the SU
-
No
xslt-engine-pool-size-max The maximum number of XSL transformers to instantiate for the SU (at the same time). It corresponds to the maximum
number of requests treated simultaneously by the component for the SU.
-
No

A xsl-parameter element has the following structure:

<xs:complexType name="XslParameter">
	<xs:simpleContent>
		<xs:extension base="xs:string">
			<xs:attribute name="name" type="xs:string" />
			<xs:attribute name="overridable" type="xs:boolean" default="false" />
		</xs:extension>
	</xs:simpleContent>
</xs:complexType>
  • Its value is a text.
  • The name attribute must match the name of a XSL parameter.
  • The overridable attribute defines whether this static value can be overriden by a dynamic value (from an incoming message).

Service unit content

The service unit has to contain the following elements, packaged in the archive:

  • the META-INF/jbi.xml descriptor file as described above,
  • it is also highly recommended to provide a WSDL description for service provider embedded in the service-unit,
  • the XSL style sheet,
  • an optional JAR containing custom functions referenced in the XSL style sheet.
service-unit.zip
  + META-INF
    - jbi.xml (as defined above)
  - service.wsdl (recommended)
  - xsl-stylesheet.xsl
  - customFunctions.jar (optional)

Example

An example of a Service Unit descriptor to provide an XSLT service:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
	xmlns:generatedNs="http://petals.ow2.org/components/xslt/version-2"
	xmlns:jbi="http://java.sun.com/xml/ns/jbi"
	xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:xslt="http://petals.ow2.org/components/xslt/version-2">

	<jbi:services binding-component="false">

		<jbi:provides
			interface-name="generatedNs:XsltInterface"
			service-name="generatedNs:Test"
			endpoint-name="TestEndpoint">

			<!-- CDK specific elements -->
			<petalsCDK:timeout>30000</petalsCDK:timeout>
			<petalsCDK:validate-wsdl>true</petalsCDK:validate-wsdl>
			<petalsCDK:forward-security-subject>false</petalsCDK:forward-security-subject>
			<petalsCDK:forward-message-properties>false</petalsCDK:forward-message-properties>
			<petalsCDK:forward-attachments>false</petalsCDK:forward-attachments>
			<petalsCDK:wsdl>XsltService.wsdl</petalsCDK:wsdl>

			<!-- Component specific elements -->
			<xslt:stylesheet>transformation.xsl</xslt:stylesheet>

			<!-- XSL parameters -->
			<generatedNs:xsl-parameters>
				<generatedNs:xsl-parameter name="street" overridable="true">
					17, rue du Parc
				</generatedNs:xsl-parameter>
				<generatedNs:xsl-parameter name="city" overridable="false">
					Grenoble
				</generatedNs:xsl-parameter>
			</generatedNs:xsl-parameters>
		</jbi:provides>
	</jbi:services>
</jbi:jbi>

Configuring the component

The component can be configured through the parameters of its JBI descriptor file. These parameters are divided in following groups:

  • JBI parameters that have not to be changed otherwise the component will not work,
  • CDK parameters that are parameters driving the processing of the CDK layer,
  • Dedicated parameters that are parameters specific to this component.

CDK parameters

The component configuration includes the configuration of the CDK. The following parameters correspond to the CDK configuration.

Parameter Description Default Scope*
acceptor-pool-size The size of the thread pool used to accept Message Exchanges from the NMR. Once a message is accepted, its processing is delegated to the processor pool thread. 1
 Runtime
acceptor-retry-number Number of tries to submit a message exchange to a processor for processing before to declare that it cannot be processed. 40
 Installation
acceptor-retry-wait Base duration, in milliseconds, to wait between two processing submission tries. At each try, the new duration is the previous one plus this base duration. 250
 Installation
acceptor-stop-max-wait The max duration (in milliseconds) before, on component stop, each acceptor is stopped by force. 500
 Runtime
processor-pool-size The size of the thread pool used to process Message Exchanges. Once a message is accepted, its processing is delegated to one of the thread of this pool. 10 Runtime
processor-max-pool-size The maximum size of the thread pool used to process Message Exchanges. The difference between this size and the processor-pool-size represents the dynamic threads that can be created and destroyed during overhead processing time.
50
 Runtime
processor-keep-alive-time When the number of processors is greater than the core, this is the maximum time that excess idle processors will wait for new tasks before terminating, in seconds.
300
 Runtime
processor-stop-max-wait The max duration (in milliseconds) of message exchange processing on stop phase (for all processors).
 15000
 Runtime
time-beetween-async-cleaner-runs The time (in milliseconds) between two runs of the asynchronous message exchange cleaner.
 2000
 Installation
properties-file Name of the file containing properties used as reference by other parameters. Parameters reference the property name using a placeholder in the following pattern ${myPropertyName}. At runtime, the expression is replaced by the value of the property.

The properties file can be reloaded using the JMX API of the component. The runtime configuration MBean provides an operation to reload these place holders. Check the service unit parameters that support this reloading.

The value of this parameter is :
  • an URL
  • a file relative to the PEtALS installation path
  • an absolute file path
  • an empty value to stipulate a non-using file.
 - Installation
monitoring-sampling-period Period, in seconds, of a sample used by response time probes of the monitoring feature. 300 Installation
activate-flow-tracing Enable ('true') or disable ('false') the flow tracing. This value can be overridden at service consumer or service provider level, or at exchange level. true Runtime
propagate-flow-tracing-activation Control whether the flow tracing activation state must be propagated to next flow steps or not. If 'true', the flow tracing activation state is propagated. This value can be overridden at service consumer level. true Runtime
component-interceptors Component interceptor configuration. See CDK Component interceptor configuration. - See Maven Petals plugin to known how to inject component interceptor configuration in component configuration

* Definition of CDK parameter scopes:

  • Installation: The parameter can be set during the installation of the component, by using the installation MBean (see JBI specifications for details about the installation sequence). If the parameter is optional and has not been defined during the development of the component, it is not available at installation time.
  • Runtime: The paramater can be set during the installation of the component and during runtime. The runtime configuration can be changed using the CDK custom MBean named RuntimeConfiguration. If the parameter is optional and has not been defined during the development of the component, it is not available at installation and runtime times.

Interception configuration

Interceptors can be defined to inject some post or pre-processing in the component during service processing.

Using interceptor is very sensitive and must be manipulated only by power users. A non properly coded interceptor engaged in a component can lead to uncontrolled behaviors, out of the standard process.

Example of an interceptor configuration:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi xmlns:jbi="http://java.sun.com/xml/ns/jbi" xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5" ...>
   <jbi:component>
      <!--...-->
      <petalsCDK:component-interceptors>
         <petalsCDK:interceptor active="true" class="org.ow2.petals.myInterceptor" name="myInterceptorName">
            <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
            <petalsCDK:param name="myParamName2">myParamValue2</petalsCDK:param>
         </petalsCDK:interceptor>
      </petalsCDK:component-interceptors>
      <!--...-->
   </jbi:component>
</jbi:jbi>

Interceptors configuration for Component (CDK)

Parameter Description Default Required
interceptor - class Name of the interceptor class to implement. This class must extend the abstract class org.ow2.petals.component.common.interceptor.Interceptor. This class must be loadable from the component classloader, or in a dependent Shared Library classloader. - Yes
interceptor - name Logical name of the interceptor instance. It is referenced at service unit level to register this interceptor for services of the service unit. See SU Interceptor configuration. - Yes
interceptor - active If true, the Interceptor instance is activated for every SU deployed on the component.
If false, the Interceptor can be activated:
-by the InterceptorManager Mbean at runtime, to activate the interceptor for every deployed SU.
-by a SU configuration 		- Yes
param[] - name The name of the parameter to use for the interceptor. - No
param[] The value of the parameter to use for the interceptor. - No

Dedicated configuration

No dedicated configuration parameter is available.

Business monitoring

MONIT traces

Each service provider implemented is able to log MONIT traces with following information:

  • on service provider invocation, when receiving an incoming request, with following attributes:
    • traceCode set to provideFlowStepBegin,
    • flowInstanceId set to the flow instance identifier retrieved from the incoming request,
    • flowStepId set to an UUID value,
    • flowStepInterfaceName set to the service provider interface name,
    • flowStepServiceName set to the service provider service name,
    • flowStepOperationName set to the operation of the invoked service provider,
    • flowStepEndpointName set to the service provider endpoint name,
    • flowPreviousStepId set to the step identifier of the previous step, retrieved from the incoming request.
  • on service provider termination, when returning the outgoing response, with following attributes:
    • traceCode set to provideFlowStepEnd or provideFlowStepFailure,
    • flowInstanceId set to the flow instance identifier retrieved from the incoming request,
    • flowStepId set to the flow step identifier defined on incoming request receipt.

Flow tracing activation

The flow tracing (ie. MONIT traces generation) is defined according to the property 'org.ow2.petals.monitoring.business.activate-flow-tracing' of the incoming JBI request. If the property does not exist, the parameter activate-flow-tracing of the service provider definition will be inspected. If no parameter is defined at service provider level, the component configuration parameter 'activate-flow-tracing' is used. Finally, by default, the flow tracing is enabled.

Monitoring the component

Using metrics

Several probes providing metrics are included in the component, and are available through the JMX MBean 'org.ow2.petals:type=custom,name=monitoring_<component-id>', where <component-id> is the unique JBI identifier of the component.

Common metrics

The following metrics are provided through the Petals CDK, and are common to all components:

Metrics, as MBean attribute Description Detail of the value Configurable
MessageExchangeAcceptorThreadPoolMaxSize The maximum number of threads of the message exchange acceptor thread pool integer value, since the last startup of the component yes, through acceptor-pool-size
MessageExchangeAcceptorThreadPoolCurrentSize The current number of threads of the message exchange acceptor thread pool. Should be always equals to MessageExchangeAcceptorThreadPoolMaxSize. instant integer value no
MessageExchangeAcceptorCurrentWorking The current number of working message exchange acceptors. instant long value no
MessageExchangeAcceptorMaxWorking The max number of working message exchange acceptors. long value, since the last startup of the component no
MessageExchangeAcceptorAbsoluteDurations The aggregated durations of the working message exchange acceptors since the last startup of the component. n-tuple value containing, in nanosecond:
  • the maximum duration,
  • the average duration,
  • the minimum duration.
 no
MessageExchangeAcceptorRelativeDurations The aggregated durations of the working message exchange acceptors on the last sample. n-tuple value containing, in nanosecond:
  • the maximum duration,
  • the average duration,
  • the minimum duration,
  • the 10-percentile duration (10% of the durations are lesser than this value),
  • the 50-percentile duration (50% of the durations are lesser than this value),
  • the 90-percentile duration (90% of the durations are upper than this value).
 no
MessageExchangeProcessorAbsoluteDurations The aggregated durations of the working message exchange processor since the last startup of the component. n-tuple value containing, in milliseconds:
  • the maximum duration,
  • the average duration,
  • the minimum duration.
 no
MessageExchangeProcessorRelativeDurations The aggregated durations of the working message exchange processor on the last sample. n-tuple value containing, in milliseconds:
  • the maximum duration,
  • the average duration,
  • the minimum duration,
  • the 10-percentile duration (10% of the durations are lesser than this value),
  • the 50-percentile duration (50% of the durations are lesser than this value),
  • the 90-percentile duration (90% of the durations are upper than this value).
 no
MessageExchangeProcessorThreadPoolActiveThreadsCurrent The current number of active threads of the message exchange processor thread pool instant integer value no
MessageExchangeProcessorThreadPoolActiveThreadsMax The maximum number of threads of the message exchange processor thread pool that was active integer value, since the last startup of the component no
MessageExchangeProcessorThreadPoolIdleThreadsCurrent The current number of idle threads of the message exchange processor thread pool instant integer value no
MessageExchangeProcessorThreadPoolIdleThreadsMax The maximum number of threads of the message exchange processor thread pool that was idle integer value, since the last startup of the component no
MessageExchangeProcessorThreadPoolMaxSize The maximum size, in threads, of the message exchange processor thread pool instant integer value yes, through http-thread-pool-size-max
MessageExchangeProcessorThreadPoolMinSize The minimum size, in threads, of the message exchange processor thread pool instant integer value yes, through http-thread-pool-size-min
MessageExchangeProcessorThreadPoolQueuedRequestsCurrent The current number of enqueued requests waiting to be processed by the message exchange processor thread pool instant integer value no
MessageExchangeProcessorThreadPoolQueuedRequestsMax The maximum number of enqueued requests waiting to be processed by the message exchange processor thread pool since the last startup of the component instant integer value no
ServiceProviderInvocations The number of service provider invocations grouped by:
  • interface name, as QName, the invoked service provider,
  • service name, as QName, the invoked service provider,
  • invoked operation, as QName,
  • message exchange pattern,
  • and execution status (PENDING, ERROR, FAULT, SUCCEEDED).
 integer counter value since the last startup of the component no
ServiceProviderInvocationsResponseTimeAbs The aggregated response times of the service provider invocations since the last startup of the component grouped by:
  • interface name, as QName, the invoked service provider,
  • service name, as QName, the invoked service provider,
  • invoked operation, as QName,
  • message exchange pattern,
  • and execution status (PENDING, ERROR, FAULT, SUCCEEDED).
 n-tuple value containing, in millisecond:
  • the maximum response time,
  • the average response time,
  • the minimum response time.
 no
ServiceProviderInvocationsResponseTimeRel The aggregated response times of the service provider invocations on the last sample, grouped by:
  • interface name, as QName, the invoked service provider,
  • service name, as QName, the invoked service provider,
  • invoked operation, as QName,
  • message exchange pattern,
  • and execution status (PENDING, ERROR, FAULT, SUCCEEDED).
 n-tuple value containing, in millisecond:
  • the maximum response time,
  • the average response time,
  • the minimum response time,
  • the 10-percentile response time (10% of the response times are lesser than this value),
  • the 50-percentile response time (50% of the response times are lesser than this value),
  • the 90-percentile response time (90% of the response times are lesser than this value).
 no

Dedicated metrics

No dedicated metric is available.

Receiving alerts

Several alerts are notified by the component through notification of the JMX MBean 'org.ow2.petals:type=custom,name=monitoring_<component-id>', where <component-id> is the unique JBI identifier of the component.

To integrate these alerts with Nagios, see Receiving Petals ESB defects in Nagios.

Common alerts

Defect JMX Notification
A message exchange acceptor thread is dead
  • type: org.ow2.petals.component.framework.process.message.acceptor.pool.thread.dead
  • no user data
No more thread is available in the message exchange acceptor thread pool
  • type: org.ow2.petals.component.framework.process.message.acceptor.pool.exhausted
  • no user data
No more thread is available to run a message exchange processor
  • type: org.ow2.petals.component.framework.process.message.processor.thread.pool.exhausted
  • no user data

Dedicated alerts

No dedicated alert is available.

Labels

user user Delete
xslt xslt Delete
se se Delete
component component Delete
petals petals Delete
components-se-family components-se-family Delete
guide guide Delete
2-4 2-4 Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.