I'm testing a IIIF manifest generator that I wrote using the iiif-presentation gem, and I'm getting Net::ReadTimeout exceptions.
Admittedly, the manifest generator is running in Virtualbox, which is also running Loris, on a desktop... and that Loris on the desktop needs to go off to Amazon over an ADSL connection to get some rather large files, so this isn't what one would expect to happen in production.
But I notice there is no way to tell osullivan/iiif-presentation to use a longer read timeout. I think the default is 60 seconds and it's not hacking it, which isn't surprising as I think I've benchmarked the download from Amazon to be around 2 minutes. Once Loris has cached the image from the Amazon server, then there's no issue running create_image_api_image_resource, since it's already cached locally. But when Loris has to struggle to pull down that image... it causes the manifest generator to lose its mind.
I suppose I could try mitigating that with retry attempts or something, but... just increasing the timeout should be sufficient.
I'm testing a IIIF manifest generator that I wrote using the iiif-presentation gem, and I'm getting Net::ReadTimeout exceptions.
Admittedly, the manifest generator is running in Virtualbox, which is also running Loris, on a desktop... and that Loris on the desktop needs to go off to Amazon over an ADSL connection to get some rather large files, so this isn't what one would expect to happen in production.
But I notice there is no way to tell osullivan/iiif-presentation to use a longer read timeout. I think the default is 60 seconds and it's not hacking it, which isn't surprising as I think I've benchmarked the download from Amazon to be around 2 minutes. Once Loris has cached the image from the Amazon server, then there's no issue running create_image_api_image_resource, since it's already cached locally. But when Loris has to struggle to pull down that image... it causes the manifest generator to lose its mind.
I suppose I could try mitigating that with retry attempts or something, but... just increasing the timeout should be sufficient.