Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore efficiency of adore-djatoka implementation #46

Open
ctgraham opened this issue Dec 13, 2017 · 1 comment
Open

Explore efficiency of adore-djatoka implementation #46

ctgraham opened this issue Dec 13, 2017 · 1 comment

Comments

@ctgraham
Copy link
Contributor

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.

@ctgraham
Copy link
Contributor Author

ctgraham commented Feb 14, 2018

We have also found that enabling SSL breaks djatoka links behind the scenes. Luke Taylor reports:

The problem is with Tomcat not trusting the cert. You can try https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Importing_the_Certificate to get it to work fine with HTTPS. It can be a pain to get working (The import doesn't always make Djatoka work depending on what files provided from the SSL vendor e.g. you are missing the proper chain) which is why so many people resort to having the Djatoka specific traffic rewrite to HTTP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant