General Information:

As we know  sun-scheduler-bc provides scheduling capabilities for initiating JBI services. The binding component is powered by http://www.opensymphony.com/quartz/, and allows you to schedule triggers to launch (consume) other JBI components. We can use this component to scheduled  “Simple“, or “Cron” or “Hybrid” trigger as we need.

When you deploy any sun-scheduler based composite application into JBI container, by default its uses “Quartz RAM Store” to define its job and this is quite good if that composite application going to run in one instance.

Problem with Quartz RAM Store:

What happens it you going to deploy this same composite application in  multiple Cluster instances ?

The answers is, trigger is going to happen in all the cluster instances at the same time and this will cause the same process runs multiple times in different instance and this is against cluster configuration.海绵宝宝

Solution:

To avoid the above problem we have to perform certain configuration in sun-scheduler-bc configuration to share the quartz job details across cluster instances using “Quartz Persistent Job Store” configuration property. So that, any one of the same composite application that belongs to different cluster instances should trigger at a time.

Follow the below steps to configure sun-scheduler-bc to define Quartz Persistent Job Store ( Glassfish cluster mode):

Note:- In this configuration I’ve use Mysql as persistent job store to store the sun-scheduler-bc composite application job details. You can choose your own data base as per quartz api support (http://svn.terracotta.org/svn/quartz/tags/quartz-1.8.6/docs/dbTables/)

Step1: To Set Up Mysql DB For Job Store

1. Create schema in Mysql db (eg: oe_sun_schedulder_bc_job_store)

2.Download the Mysql based job store sql from below link

http://svn.terracotta.org/svn/quartz/tags/quartz-1.8.6/docs/dbTables/tables_mysql.sql or check this attachment for same sql scripts Quartz_Mysql_Job_store

3. Run the sql script into above created schema.

Now DB set up is done.

Step 2: Configure Glassfish ESB server to create new JDBC resource to access the above created database (oe_sun_schedulder_bc_job_store) . In this example i have created JDBC resources “jdbc/OESunSchedulderBCDS” and made it available on all targets i.e. the cluster nodes you desire.

JDBC resource for sun-scheduler-bc Quartz Persistent JobStore

Step 3: Configure sun-scheduler-binding to point to Quartz Persistent Job Store,  JDBC resources “jdbc/OESunSchedulderBCDS“

1. Navigate to  JBI > Components > sun-scheduler-binding . Then select “Configuration” tab to show  its details.

2. Under “View/Update Instance:” configuration property select cluster instance you want to configure from tthe drop down menu.

3. Change the below configuration properties:

a. Use Quartz RAMJobStore to set to “FALSE”

b. provide “Quartz Persistent JobStore JNDI URL ” value as JDBC resources you have configured in step 2 ( i.e. Quartz Persistent JobStore JNDI URL = jdbc/OESunSchedulderBCDS

Repeate 2 & 3 for all the cluster instances you want to configure.

sun-scheduler-bc Quartz persistent job store

Now all the configuration is done to share the share quartz  job across cluster instances in sun-scheduler-bc.

Demo:

In this demo I’ve created 1 node agent (Nodeagent1) , 2 clusters (cluster1 and cluster 2) and four instances (Instance1 , Instance2, Instance3, Instance4) . Instance1 & 2 belongs to cluster1 and Instance3&4 belongs to cluster2 for testing the above scenario.

Demo Cluster config for testing sun-scheduler-bc Quartz Persistent JobStore

I have created simple sun-scheduler-bc based composite application to receive the trigger message and print in the log

Simple sun-scheduler-bc demo BPEL

Please check this attachment for BPEL and Composite application project SchedulderbcClusterJobStore

Then deploy the above composite application in Cluster1 and Cluster2. After you deploy the above composite application verify DB to make sure corresponding  job has been created under “qrtz_job_details” table.

qrtz_job_details table

Then verify the log in all four cluster instance 1,2,3&4 to make sure trigger happens only in any one of the instance at time.

log result