Potential problem with resolving of ResourceProxy entries (doubled requests)

[teckart]

Jörg Knappen:

ich habe bemerkt, dass vor einem Ressourcenzugriff durch andere sich zuerst mal das VLO die Ressource aus unserem Repo zieht.

Das führt zu folgenden m. E. unerwünschten Effekten:

• Das VLO zeigt zwar schnell die Metadaten an, auf den Link zur Ressource muss der Benutzer aber warten
• Erhöhte Netzlast, da die Ressource zweimal angefordert wird, einmal durch das VLO und dann durch den Benutzer selbst

Example:

​http://catalog.clarin.eu/ds/vlo/?wicket:bookmarkablePage=:eu.clarin.cmdi.vlo.pages.ShowResultPage&q=GRUG&docId=hdl:11858/00-246C-0000-0008-5F2A-0

Dieser URL führt zu den folgenden beiden http-Requests auf unserem Server:

192.87.79.171 - - [11/Mar/2013:11:19:32 +0100] "GET /fedora/objects/clarind-uds:grug/datastreams/LINK/content HTTP/1.1" 307 -
192.87.79.171 - - [11/Mar/2013:11:19:32 +0100] "GET /grug/ HTTP/1.1" 200 11224

wobei der erste Request aus der Auflösung der Handle resultiert und der zweite Request die Folge der Weiterleitung auf unsere "Landing Page" ist. catalog.clarin.eu lädt in der Tat die Landeseite, die zum Glück nur 11224 Bites groß ist. Auch dann, wenn der erste Request keine Weiterleitung wäre, sondern direkt auf die Landeseite ginge, würde diese als ganzes geladen.

(Zur Strukturierung unserer PIDs siehe auch ​http://de.clarin.eu/mwiki/index.php/Diskusionsgrundlage:_Repository_%26_PIDs )

[teckart]

This functionality was originally implemented to additionally display a "name" of a resource identified by a Handle. As the HandleResolver? still does not work completely on catalog.clarin.eu (#136), a workaround was implemented to resolve the URL directly by using the Handle REST interface and display the resolved URL. This leads to a request on the Handle resolver + a request on the resource location (source:vlo/trunk/vlo_web_app/src/main/java/eu/clarin/cmdi/vlo/pages/LinkPanel.java). Apparently this (old) workaround does not work as expected (e.g. for the URL in the ticket).

[teckart]

Alternative resolving solution was fixed (omiting requests on the resource's server) in trunk (r3362). Reported behaviour should not occur anymore.