Database Reference
In-Depth Information
Consider a scenario where your composite begins processing an instance by
consuming messages from a JMS queue. During peak load, if sufficient threads
are not available to the polling adapter, the overall performance of the composite
is degraded. There may be no problem with your infrastructure and it may
be capable of handling extra load by allocating more threads. The easiest
way to overcome this bottleneck is to increase the value of the
ad-
apter.jms.receive.threads
property that controls the number of threads
from its default value of
1
. This is a binding property that can be set in an indi-
vidual composite as shown:
<property name="adapter.jms.receive.threads" type="xs:string" many="false">4</property>
We cannot address all scenarios that may cause a specific composite to behave
poorly, as they are unlimited. However, we can provide the means and direction
to identify poorly behaving composites and help retrieve the specific composite
instance ID of the offending instance, so that we may navigate to its details and
find out more of what's going on.
Refer to the
ReadMe.txt
file of this chapter to get a copy of all SQL scripts
listed here.
Average,
minimum,
and
maximum
duration
of
components
These queries look complex, but they actually are not. The reason they look
complicated is because of the way they organize the data into a more easy to
read format.
This first query, when run against the
[PREFIX]_SOAINFRA
schema, returns
the name of the BPEL or BPMN component name, the partition it is deployed
to, its state, as well as average, minimum, and maximum execution times along
with the total count. The following query is filtered to retrieve statistics for the
last 24 hours, via the
sysdate-1
clause. If you choose to, you can further
limit the query to a specific composite (
COMPOSITE_NAME LIKE '%<com-
