We've noticed that when the ThingISBN API is running slowly or down, that libraries that enable this preference can cause themselves a denial of service when patrons try to load the detail page of a book that has Editions. It would be good to make this not block the loading of the page, the Editions tab isn't the primary viewed tab anyway - it would be fine to load in it's data in the background. Thanks for looking, Liz
Specifically, when the patron clicks on the detail many times, because it appears that the page didn't load the first time.
Upon further review, it appears that the slowness is caused by books that have many editions (think Hamlet).
The problem code is in C4::XISBN: # loop through each ISBN and scope to the local collection for my $response_data( @{ $response->{ isbn } } ) { next if $unique_xisbns->{ $response_data->{content} }; $unique_xisbns->{ $response_data->{content} }++; my $xbiblio= _get_biblio_from_xisbn($response_data->{content}); next unless $xbiblio; push @xisbns, $xbiblio if $xbiblio && $xbiblio->{biblionumber} ne $biblionumber; } Basically, we run a search for each returned isbn to see if it's in our catalog. Some of these titles have hundreds of ISBNs, especially for the classics. For example, the brothers karamazov has nearly 500 isbns in ThingISBN. The solution could be A) convert these hundereds of small queries into one or more big queries and/or B) move the this to the front end where we get the ThingISBN data via javascript then search our own catalog via the rest api