Skip to content

Explore efficiency of adore-djatoka implementation #46

@ctgraham

Description

@ctgraham

In the DevOps December call, we noted some frustrations with adore-djatoka.

It seems that adore-djatoka is implemented with default URLs like:
http://islandora-server/adore-djatoka/resolver?url_ver=Z39.88-2004&rft_id=http%3A%2F%2Fislandora-server%2Fislandora%2Fobject%2Fns%25pid%2Fdatastream%2FJP2%2Fview%3Ftoken%3Dmd5&svc_id=info%3Alanl-repo%2Fsvc%2FgetRegion&svc_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajpeg2000&svc.region=1536%2C2560%2C256%2C256&svc.level=3

Assuming a reverse proxy for djatoka, and djatoka hosted on a non-web facing tomcat server, this means a request to the webserver traverses:

  • User Agent to Webserver's adore-djatoka/resolver handler
    • Webserver's adore-djatoka/resolver handler to Tomcat's adore-djatoka/resolver
      • Tomcat's adore-djatoka/resolver to Webserver's /islandora/object/PID/datastream/DS/view
        • Webserver's /islandora/object/PID/datastream/DS/view to Fedora's datastream via API
          • Return back up the call stack

The round trip from Tomcat to the webserver to fetch a Fedora datastream seems unnecessary. If the rft_id were formatted such that the Tomcat server could read directly from the Fedora server, this would save a potentially expensive network hop.

Is this just a configuration issue, or is it a design problem?

We also noted that adore-djatoka is not caching (or at least not effectively caching) requests, but is rather creating new temp files for every request.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions