You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
adore-djatoka/resolver
handleradore-djatoka/resolver
handler to Tomcat'sadore-djatoka/resolver
adore-djatoka/resolver
to Webserver's/islandora/object/PID/datastream/DS/view
/islandora/object/PID/datastream/DS/view
to Fedora's datastream via APIThe 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.
The text was updated successfully, but these errors were encountered: