Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-3723

Exporting AIP packages problem

    Details

    • Type: Bug
    • Status: Received (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 5.2
    • Fix Version/s: None
    • Component/s: DSpace API, JSPUI
    • Labels:
      None
    • Environment:
      Linux CentOS 6.5
    • Attachments:
      0
    • Comments:
      0
    • Documentation Status:
      Needed

      Description

      Hi,

      We have an installed process that periodacally exports all items, collections and communities from DSpace using the AIP packager feature. But sometimes this proccess breaks unexpectally. For instance this exception:

       

      Exception: Error exporting METS for DSpace Object, type=ITEM, handle=XXXXX/XXX, dbID=XXXXX
      org.dspace.content.packager.PackageValidationException: Error exporting METS for DSpace Object, type=ITEM, handle=XXXXX/XXX, dbID=XXXXX, Reason: edu.harvard.hul.ois.mets.helper.MetsException: ID "bitstream_3" already exists
      at org.dspace.content.packager.AbstractMETSDisseminator.disseminate(AbstractMETSDisseminator.java:280)
      at org.dspace.content.packager.DSpaceAIPDisseminator.disseminate(DSpaceAIPDisseminator.java:160)
      at org.dspace.content.packager.AbstractPackageDisseminator.disseminateAll(AbstractPackageDisseminator.java:103)
      at org.dspace.app.packager.Packager.disseminate(Packager.java:641)
      at org.dspace.app.packager.Packager.main(Packager.java:460)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:606)
      at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:226)
      at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:78)
      Caused by: edu.harvard.hul.ois.mets.helper.MetsException: ID "bitstream_3" already exists
      at edu.harvard.hul.ois.mets.helper.MetsValidator.validate(MetsValidator.java:68)
      at edu.harvard.hul.ois.mets.helper.MetsVElement.validate(MetsVElement.java:68)
      at edu.harvard.hul.ois.mets.helper.MetsValidator.validate(MetsValidator.java:78)
      at edu.harvard.hul.ois.mets.helper.MetsVElement.validate(MetsVElement.java:68)
      at edu.harvard.hul.ois.mets.helper.MetsValidator.validate(MetsValidator.java:78)
      at edu.harvard.hul.ois.mets.helper.MetsVElement.validate(MetsVElement.java:68)
      at edu.harvard.hul.ois.mets.helper.MetsValidator.validate(MetsValidator.java:78)
      at edu.harvard.hul.ois.mets.helper.MetsVElement.validate(MetsVElement.java:68)
      at org.dspace.content.packager.AbstractMETSDisseminator.writeZipPackage(AbstractMETSDisseminator.java:386)
      at org.dspace.content.packager.AbstractMETSDisseminator.disseminate(AbstractMETSDisseminator.java:259)

       

      We identify that there are two different sequences. One in bundle2bitstream (field: bitstream_order) table and the other in bitstream table (sequence_id). I don't know the reason for having two different sequences, perhaps a legacy issue. In this reported issue we had:

      bundle2bitstream.bitstream_order bitstream.sequence_id
      0 1
      1 2
      2 3
      3 3
      4 4
      5 5
      6 6

       

      Not sure why the  bitstream.sequence_id = 3 field repeats itself but I think it must be related with the ordering feature in the adminstrator backoffice interface.

      The solution to this problem it's to manually correct the bitstream sequence. 

       

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              paulo_graca Paulo Graça
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: