There is a knot to untie related to concurrency: the ImagingServlet currently instanciates a new CachingImageStreamer for every request. This also means a different instance of the HierarchyManager (although potentially using the same jcr session, to be checked)

The currentJobs map of CachingImageStreamer, which is used to lock and avoid multiple requests for the same generation job is thus also a different instance (it is not static). I can't easily demonstrate the potential issue (if any) with the image gallery of stk, but I suspect that it might useless as it is. If this can be confirmed, we might need to make that map static, or use the same CachingImageStreamer instance (both cases would imply API changes at the ParameterProviderFactory level)

Another thing to consider:

• make the expiration of the currentJobs map longer: that long generation jobs would really just be triggered once - at the moment, if a job takes n times longer than 500ms, it might run n times in parallel. Keeping the expiration as some form of safety net.
• manually remove the jobs of the map once done. (so that they don't stay longer than necessary)