Is there locking on Spring managed beans inside RecursiveTask

Question

Technology stack

• Web application
• Java 1.7
• Spring Framework 4

The problem

1. I need to be able to process ZIP files containing documents in the application, unzip them recursively. What I mean by recursively - if the ZIP contains other ZIP files they also should be unzipped. Then all documents inside all the archives should be processed.

2. Point 1 should be executed in parallel in order to speed up the process.

Implementation

• I decided to use the ForkJoinFramework introduced in Java 7. So I ended up with having Spring managed singleton service ZipService (having process(zip) method) that uses Spring managed ForkJoinPool to invoke the ZipPartitioner (a RecursiveTask I created for partitioning the contents from the ZIP file). The ZipPartitioner's compute() method check if the set of ZIP contents is smaller enough (document set size is 1) to compute directly or if it should continue with the partitioning. If it should be computed directly I check if the current content/file is actually a file to be processed or it is another (nested) ZIP. Here comes the interesting part - when I create the ZipPartitioner in ZipService I pass this to its constructor, so I have a reference to the ZipService. Then if in the compute directly logic it turns out the content is actually a ZIP again, I call the process(zip) method from the ZipService's reference so the process can start all over again recursively.

Result

• Surprisingly the implementation worked very well and decreased the processing duration 3 times. Then I decided to benchmark the implementation with JMeter. It worked fine with 5 concurrent requests but it hangs with 10+ requests. The execution blocks when ZipPartitioner tries to call the process(zip) method on the ZipService's instance. It doesn't matter how many threads are there in the ForkJoinPool - I checked with 1, 10, 30 and 1000.

Question

• I think there is something generally wrong in this approach - passing Spring managed bean to RecursiveTask, but it worked with smaller request numbers. So can someone point me to why this breaks and why it works? How would you approach this problem?
• I suspect that the subsequent requests to the ZipService somehow make Spring lock it and that way prevent the recursive call from computeDirectly method. Do you find something meaningful in my thoughts or are they rubbish?

Let me know what is unclear in my explanation (I bet there will be something).

Answer 1

A few advice that should help:

• Do a thread dump (e.g. with visualvm) and see what is blocked
• Try to minimize the number of forked tasks
• Consider iteration instead of recursion