[MGNLIMG-50] Concurrency issues / review Created: 26/May/09  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Magnolia International Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MGNLIMG-53 Write tests for concurrency issues Closed
relation
is related to MGNLIMG-43 Concurrency issue when generating ima... Closed
is related to MGNLIMG-121 Upgrade to Guava 16 Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

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)


 Comments   
Comment by Christopher Zimmermann [ 09/Dec/13 ]

This issue is still valid as of Dec 6, 2013 according to gjoseph.

Comment by Magnolia International [ 13/Mar/14 ]

http://www.cs.umd.edu/projects/PL/multithreadedtc/overview.html might be useful, although the library development isn't active, it still seems to be "the" reference. (our current concurrency tests have all sort of multi-threading and synchronization code in the tests themselves, which make them 1) unreadable 2) unmaintainable 3) unreliable

http://code.google.com/p/multithreadedtc/
http://code.google.com/p/multithreadedtc-junit4/

Also read http://jmock.org/threading-executor.html and neighboring pages.

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 02:11:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.