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
When image thumbs are rendered on demand in gallery (enableImageThumbs = false), if image formats not supported by java are listed (webp, svg, heic, emf...) the same fixed size thread pool is used by gallery and imagemagick converter, and that can cause very slow rendering of error images, because of "deadlock" until timeouts.
Furthermore, if more images than max Sleuthkit internal database connection pool are asked at the same time, that sometimes can deadlock in first gallery rendering. The last looks like a TSK bug, but limiting gallery thread pool size to TSK max pool size seems to workaround it.
The text was updated successfully, but these errors were encountered:
Actually the first problem is not a deadlock, but very slow wrong rendering. When imagemagick converter times out, it returns an error "X" image and returns the thread to the pool to be reused.
Second problem seems a deadlock.
lfcnassif
changed the title
Deadlock in gallery if enableImageThumbs = false with uncommon formats
Deadlock or very slow wrong rendering in gallery if enableImageThumbs = false
Nov 11, 2020
lfcnassif
changed the title
Deadlock or very slow wrong rendering in gallery if enableImageThumbs = false
Deadlock or very slow rendering with error in gallery if enableImageThumbs = false
Nov 12, 2020
When image thumbs are rendered on demand in gallery (enableImageThumbs = false), if image formats not supported by java are listed (webp, svg, heic, emf...) the same fixed size thread pool is used by gallery and imagemagick converter, and that can cause very slow rendering of error images, because of "deadlock" until timeouts.
Furthermore, if more images than max Sleuthkit internal database connection pool are asked at the same time, that sometimes can deadlock in first gallery rendering. The last looks like a TSK bug, but limiting gallery thread pool size to TSK max pool size seems to workaround it.
The text was updated successfully, but these errors were encountered: