Uploaded image for project: 'Islandora'
  1. Islandora
  2. ISLANDORA-1234

Create Bag on object modification loop possibly caused by users who rarely logout



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 7.x-1.4, 7.x-1.5
    • Fix Version/s: 7.x-1.6
    • Component/s: BagIt
    • Labels:


      Observed in dblog a bag being generated over and over again; the same bag was being generated practically every minute for over 24 hours.

      I was working on batch cleanup issues during this same timeframe and had cleared data from the batch tables. I believe the clearing of batch data effectively eliminated batch as the source of the issue.

      Started reviewing islandora_bagit.module code to increase understanding, and landed on:

      function islandora_bagit_create_bag_on_shutdown() {
      if (isset($_SESSION['islandora_object']))

      { islandora_bagit_create_bag($_SESSION['islandora_object']); // Clear this variable in the session so the Bag isn't generated again. unset($_SESSION['islandora_object']); }


      Examined my drupal's session table, examining each of the session's BLOBs, and found a session containing references to "islandora_bagit".

      I deleted the session in question, which is attached to this issue. Sure enough, the bag in question stopped generating in the observed looped fashion.

      Putting two and two together, I realized function islandora_bagit_create_bag_on_shutdown() is supposed to run on logout, but I had not actually logged out. I had just shut my laptop and went home, came back in the next day and picked up where I left off, all without logging out and in again. Typical behavior...

      After observing the same bag being generated at a frequency of practically every minute for over 24 hours, I believe it's possible for a bagit loop to happen, due to the user not logging out and possibly due to factors with the data stored in the session.

      I examined the offending object's foxml in the objectStore and it's datastreams, and the files were not being updated in the continuous manner that should logically trigger an object modification event; I don't believe the file's last modified dates were a factor in triggering the bagit loop.

      I suspected checksum checking and PREMIS events to be triggering the export event, due to audit stream updating, but my research proved that was not the case.

      I believe the key is the user wasn't logging out, which of course did not trigger unset($_SESSION['islandora_object']);

      The export loop kept looping in a odd way however, which may have something to do with the session data technique/methodology.

      For the object in question, I certainly do have an odd number of revisions on RELS-EXT and POLICY datastreams; maybe an errant XACML function is polluting the waters of understanding... I certainly did not manually update RELS-EXT 30 times, nor POLICY 15 times...

      I updated the policy containing the object once (1) yesterday, but not 29 additional times...




            • Assignee:
              markj Mark Jordan
              bradspry Brad Spry
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: