Cycle Overview

Cycle System Levels

When using OIPA Cycle for pending activity processing, activities may be configured to process according to OIPA system levels. Applicable levels for processing batch activities are:

Architecture

The Cycle subsystem drives processing of transactions through a Cycle Grid, which is comprised of a set of Cycle Agents. Each Cycle Agent is a separate JVM instance, which acts as a processing node in the Grid. A special application called a Cycle Client submits tasks to the Cycle Grid to direct what type of Cycle processing the group is to work on. The following is a high-level diagram showing how the different collaborators work together to start processing a Cycle run.

Cycle Agents

Cycle Agents are the programs that execute the tasks that comprise the Cycle batch process. Each Cycle Agent runs in its own Java Virtual Machine (JVM). Depending on the number of tasks that must be executed during Cycle processing, any number of JVMs may be used to run the desired number of Cycle Agents. The JVMs may be started on one or more physical machines. If more than one machine is used, they will be effectively clustered via the Coherence clustered caching and messaging system.

The following conceptual deployment diagram shows how the Cycle Agents may be distributed between multiple machines and JVMs. The boxes labeled "T" represent the threads controlled by the Agents to perform the units of work.

Cycle Client

Cycle Client is a standalone command line application used to control the Cycle process. It allows you to commands to all the Cycle Agents in order to start and stop the process.

Main Database Tables

Deployment

Cycle Agent operates inside a web container, like WebLogic or WebSphere. The Cycle Client still operates as a standalone application.

Configuration Files

Cycle.properties – Refer to the Client Cycle.properties section below for the properties related to the Cycle Client. Refer to the Agent Cycle.properties section below for the properties related to the Cycle Agent.

cycle-coherence-config.xml – This file controls the coherence cluster. Do not alter this file unless you have an in-depth understanding of coherence. The information in this file is based on how the installation was performed. The well-known-address is how you specify what machines are allowed to join the Cycle cluster.

Note: If you try to access a machine/IP address which is not in the cluster, you will get an error.

cycle-coherence-cache-config.xml – This is a default file that defines how coherence caches are configured in terms of best practices.

log4j.xml – This file controls the log files' level of detail. Do not alter this file unless you have an in-depth understanding of this technology.

client-appContext.xml – Only used for Cycle Client. This is used to auto-wire data access layer and business logic layer classes. This file should not be modified.

cycle-spring-beans.xml – Only used for Cycle Web/Agent. This is used to auto-wire data access layer and business logic layer classes. This file should not be modified.

Client Cycle.properties

cycle.period is the number of seconds that the Cycle Agent will wait before checking for additional work.

cycle.batchSize is the maximum number of Cycle tasks that will process in the Cycle Grid. Consider the following:

cycle.groupSize determines the number of Cycle work items to group together and execute on a single thread in the cluster.

grid.taskSubmissionThreadPoolSize is the number of threads dedicated to submitting tasks to the grid for processing. Increasing this number can speed up how quickly tasks are distributed to the grid.

updatestats.run specifies whether statistics on the AsCycle table should be updated during policy level of cycle processing. It defaults to No if not specified.

updatestats.degree determines the degree of parallelism.

Web/Agent Cycle.properties

Refer to the OIPA System Properties document on OTN for an explanation of other properties related to Cycle Agent.

NOTE: In order for the Cycle Agent to be used in conjunction with Scheduled Valuation, two other options must be set in the Agent's Cycle.properties file.

Coherence

The Coherence cluster configuration in cycle-coherence-config.xml must be modified to include each Cycle Client and Agent that will participate in the Cycle group.

Since each Cycle member exists in its own JVM process and each member may be spread across multiple machines, the Cycle members in the same Cycle group must communicate. The messaging functionality of Coherence is used to accomplish this communication.

It is required that all Cycle members in the same Cycle group be configured in the same Coherence cluster.

The top of the file contains a section that allows for the addition of each machine that will participate in the Cycle group. Every Cycle Client and Agent that participates in a given Cycle group must be contained in this section. Also, each OIPA instance, if used for cycle processing, should also be listed in this section, as OIPA has the ability to submit work to the Cycle group. In the case that a machine is not included in the Coherence configuration, the machine will not be able to join the Cycle group and will encounter issues starting up.

When configuring the well-known-address list, keep the following in mind:

A sample configuration:

<?xml version="1.0" encoding="UTF-8"?>
<cluster-config>
<member-identity>
<cluster-name>PRODCLUSTER</cluster-name>
<member-name>CYCLEAGENT1</member-name>
</member-identity>
<unicast-listener>
<address>123.456.78.10</address>
<port>42222</port>
<port-auto-adjust>false</port-auto-adjust>
<well-known-addresses>
<socket-address id="1">
<address>123.456.78.10</address>
<port>42222</port>
</socket-address>
<socket-address id="2">
<address>123.456.78.11</address>
<port>42222</port>
</socket-address>
<socket-address id="3">
<address>123.456.78.12</address>
<port>42222</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>

The Coherence cache configuration in cycle-coherence-cache-config.xml configures the processing configuration on each Cycle Agent. This file must be modified only for each Cycle Agent, in order to uniquely identify the task processors that will be working in the Cycle Cluster. If the identifiers are not unique across all Agents in the cluster, the Agents with duplicate identifiers will not process any work.

The cache configuration only needs to be configured for Cycle Agents. It does not need to be modified for OIPA instances or Cycle Clients.

The following section highlights the most significant change for the cache config file. This is an example of the cache config file for a Grid Processing node (a Cycle Agent).

<cache-config xmlns:processing="class:com.oracle.coherence.patterns.processing.configuration.ProcessingPatternNamespaceHandler">

<processing:cluster-config pof="true">

<processing:dispatchers>

<processing:task-dispatcher displayname="Task Dispatcher" priority="1" />
<processing:logging-dispatcher displayname="Logging Dispatcher" />
<processing:local-executor-dispatcher displayname="Local Dispatcher" />

</processing:dispatchers>

<!-- MAKE SURE THAT ALL IDs ARE UNIQUE ACROSS THE CLUSTER, OR THE MEMBER WILL NOT PARTICIPATE IN GRID PROCESSING -->

<processing:taskprocessors>

<processing:taskprocessordefinition id="CycleTaskProcessor" displayname="Cycle Task Processor" type="SINGLE" taskpattern="SingleTask">
<processing:default-taskprocessor id="CycleTaskProcessor" threadpoolsize="15"></processing:default-taskprocessor>
</processing:taskprocessordefinition>

</processing:taskprocessors>

</processing:cluster-config>

  1. Make sure that each Cycle Agent/Cycle Web instance is using its own cycle-coherence-cache-config.xml file. You cannot share a single cycle-coherence-cache-config.xml file.
  2. Make sure the ID attributes in the processing:taskprocessors XML section are unique across the entire cluster. In the example above, you must have a unique identifier for all items that are underlined and highlighted. There are six identifiers in total.

NOTE: If your identifiers are not unique across ALL Cycle Agents in the cluster, those Agents with duplicate identifiers will not process work. There will be no obvious exception in this instance.

The following are possible changes to this file:

Change the threadpoolsize attribute on the processing:default-taskprocessor element with the ID "CycleTaskProcessor". This includes processing activities on a policy or a plan, or performing scheduled valuation/scheduled computation on a single policy (or segment for scheduled computation). Its a generic tasks tend to be more processing intensive, it is recommended that more threads are given to this thread pool.

 

 

 

 

 

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. About Oracle Insurance | Contact Us