Explore efficiency of adore-djatoka implementation

[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.

[ctgraham]

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.