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.