Chapter 6. Advanced Tutorials

Create a new project.

$ oc new-project eap-tx-demo

Add the view role to the default service account, which will be used to run the underlying pods. This enables the service account to view all the resources in the eap-tx-demo namespace, which is necessary for managing the cluster.

$ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default

For automated transaction recovery to work, the JBoss EAP application must use a ReadWriteMany persistent volume.

Provision the persistent volume expected by the eap-cd-tx-recovery-s2i application template to hold the data for the ${APPLICATION_NAME}-eap-claim persistent volume claim.

This example uses a persistent volume object provisioned using the NFS method with the following definition:

$ cat txpv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: txpv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /mnt/mountpoint
    server: 192.168.100.175

Update the path and server fields in the above definition for your environment, and provision the persistent volume with the following command:

$ oc create -f txpv.yaml
persistentvolume "txpv" created

$ oc get pv
NAME      CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
txpv      1Gi        RWX           Retain         Available                                      26s

# chmod -R 777 /mnt/mountpoint

# cat /etc/exports
/mnt/mountpoint *(rw,sync,anonuid=185,anongid=185)

# exportfs -va
exporting *:/mnt/mountpoint

# setsebool -P virt_use_nfs 1

Modify the eap-app deployment configuration with the definition of JAVA_OPTS_APPEND and JBOSS_MODULES_SYSTEM_PKGS_APPEND environment variables.

$ oc get dc
NAME                REVISION   DESIRED   CURRENT   TRIGGERED BY
eap-app             1          1         1         config,image(eap-app:latest)
eap-app-migration   1          1         1         config,image(eap-app:latest)

$ oc set env dc/eap-app \
-e JBOSS_MODULES_SYSTEM_PKGS_APPEND="org.jboss.byteman" \
-e JAVA_OPTS_APPEND="-javaagent:/tmp/src/extensions/byteman/byteman.jar=script:/tmp/src/src/main/scripts/xa.btm"
deploymentconfig "eap-app" updated

This setting will notify the Byteman tracing and monitoring tool to modify the XA transactions processing in the following way:

List running pods in the current namespace:

$ oc get pods | grep Running
NAME                        READY     STATUS      RESTARTS   AGE
eap-app-2-r00gm             1/1       Running     0          1m
eap-app-migration-1-lvfdt   1/1       Running     0          2m

Issue a new XA transaction.

Issue a second XA transaction using your browser at http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec.

Scale the cluster down.

$ oc scale --replicas=0 dc/eap-app
deploymentconfig "eap-app" scaled

Watch the log of the migration pod and notice how transaction recovery is performed. Wait for the recovery to finish:

$ oc logs -f eap-app-migration-1-lvfdt
Finished Migration Check cycle, pausing for 30 seconds before resuming
...
Finished, recovery terminated successfully
Migration terminated with status 0 (T)
Releasing lock: (/opt/eap/standalone/partitioned_data/split-1)
Finished Migration Check cycle, pausing for 30 seconds before resuming
...

Scale the cluster back up.

$ oc scale --replicas=1 dc/eap-app
deploymentconfig "eap-app" scaled

Notice the table contains entries for both transactions. It looks similar to the following output:

The content in the above table indicates that, although the cluster was scaled down before the second XA transaction had chance to finish, the migration pod performed the transaction recovery and the transaction was successfully completed.