Ability to specify read/connection timeout for reading from URL

[ghost]

Currently, Thumbnails.of(url) opens a URL connection without specifying a read or connection timeout. This could result in a thread blocking indefinitely under certain circumstances (it happened to me in a server side application). It would be desirable to give the user the ability to specify a timeout and have that timeout, in turn, be applied to the URLConnection object used (it has a method for that).

We can assist in providing that fix if you are interested.

Thanks.

[EagleLizard]

+1 to this. I am running into this error right now where heavily compressed PNG images get expanded to unpredictable sizes during conversion from a URL connection. This causes the thread to run out of heap space and crash without warning.

[coobird]

Thank you for taking the time to file the issue, @spinneret.

I'm a little reluctant to way to control connection-related timeouts through the API at the moment. (There are some implementation issues that could complicate adding such functionality, and I'm not quite sure the most elegant way to change the API to support it at the moment.)

That said, I see the validity in the need to adjust connection-related parameters such as timeout and proxies, so I will keep this ticket open as a reminder that such functionality would be useful to have.

In the meantime, there appears to be some ways to control the network client of the Java connection-related parameters through the system properties (or runtime VM options), so I can refer you to those as a quick fix until I make such changes. (In particular, you may want to check out sun.net.client.defaultConnectTimeout and sun.net.client.defaultReadTimeout.)

[coobird]

@EagleLizard, thank you for bringing up the issue of handling files that could potentially cause problems.

In your particular instance, it sounds like you may be describing a PNG bomb or the like, in general, they are something that is outside the control of Thumbnailator, as image decompression is performed by the ImageReader implementation which is registered with the Image I/O API, which is not part of Thumbnailator.

This isn't particularly an issue with using a network to download such image data, so it's not directly related to this issue. In any case, it's an interesting point that could be (partially) addressed in the future within Thumbnailator, so I've opened a new issue (#105).