Uploaded image for project: 'Cloud Enablement'
  1. Cloud Enablement
  2. CLOUD-2247

[EAP] Transaction recovery - attempt to reuse PV already containing split-n directory leads to not-empty transaction history or exception when launching the pod

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not a Bug
    • Icon: Major Major
    • None
    • None
    • BPMS, BRMS, EAP6, EAP7, JDG6, JDG7, JDV, RH-SSO
    • None
    • Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial, User Experience
    • Workaround Exists
    • Hide

      After shutting down the first launch of the demo, mount the remote NFS mountpoint to different directory, and delete its content prior re-using it (e.g. do "rm rf split*" for PVs provisioned via NFS plug-in) or use a completely new / empty NFS folder on the remote server.

      Show
      After shutting down the first launch of the demo, mount the remote NFS mountpoint to different directory, and delete its content prior re-using it (e.g. do "rm rf split *" for PVs provisioned via NFS plug-in) or use a completely new / empty NFS folder on the remote server.
    • Hide

      How reproducible:
      Always

      Steps to Reproduce:
      1) Deploy demo of automated EAP TX recovery feature as described in

      "Example Workflow: Illustration of the Automated Transaction Recovery Feature of the JBoss EAP for OpenShift Image when Scaling Down the Cluster"

      tutorial
      2) Launch the application && issue first transaction (using e.g. "Mercedes/Benz" as key/value pair, click "Submit" button),
      3) Delete the OpenShift project altogether (together with deleting the persistent volume definition):

      $ oc delete project eap-tx-demo
$ oc delete pv txpv

      4) Run that demo again, create "txpv" again pointing to the same NFS directory on the remote host (use the same 'server' and 'path' configuration when deploying the PV).
      5) Launch the aplication

      Current result:
      Entries present in split-n directories already present in PV are handled within transaction recovery (when application is launched, "Mercedes/Benz" key/value pair is visible even when no transaction so far has been issued in the second run of the application yet)

      Expected result:
      No previous transactions / transaction history is visible (IOW the EAP TX recovery functionality should remove any pre-existing content of split-n directories prior launch of the first pod).

      Workaround:
      After shutting down the first launch of the demo, mount the remote NFS mountpoint to different directory, and delete its content prior re-using it (e.g. do "rm rf split*" for PVs provisioned via NFS plug-in) or use a completely new / empty NFS folder on the remote server.

      Show
      How reproducible: Always Steps to Reproduce: 1) Deploy demo of automated EAP TX recovery feature as described in "Example Workflow: Illustration of the Automated Transaction Recovery Feature of the JBoss EAP for OpenShift Image when Scaling Down the Cluster" tutorial 2) Launch the application && issue first transaction (using e.g. "Mercedes/Benz" as key/value pair, click "Submit" button), 3) Delete the OpenShift project altogether (together with deleting the persistent volume definition): $ oc delete project eap-tx-demo $ oc delete pv txpv 4) Run that demo again, create "txpv" again pointing to the same NFS directory on the remote host (use the same 'server' and 'path' configuration when deploying the PV). 5) Launch the aplication Current result: Entries present in split-n directories already present in PV are handled within transaction recovery (when application is launched, "Mercedes/Benz" key/value pair is visible even when no transaction so far has been issued in the second run of the application yet) Expected result: No previous transactions / transaction history is visible (IOW the EAP TX recovery functionality should remove any pre-existing content of split-n directories prior launch of the first pod). Workaround: After shutting down the first launch of the demo, mount the remote NFS mountpoint to different directory, and delete its content prior re-using it (e.g. do "rm rf split *" for PVs provisioned via NFS plug-in) or use a completely new / empty NFS folder on the remote server.

      Attempt to reuse previously used persistent volume (PV already containing split-n directory) for transaction recovery leads either to:

      • Transaction history not being empty (at subsequent launch of the application it's possible to see transactions completed in previous / unrelated run), or to
      • Error (JVM exception in the case some of the present split-n directories already has "corrupted" directory structure).

      Workaround: Is always to clear the content of the remote data store, prior reusing the persistent volume (e.g. perform

        rm -rf split-*

      ) for the PV provisioned via the NFS plug-in (perform identical actions on the directory content for other OpenShift PV provisioners).

              Unassigned Unassigned
              rhn-jlieskov Ján Lieskovský (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: