[CAMEL-5704] Split inside Split - Parallel processing issue - Thread is getting wrong Exchange when leaving inner split

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.9.3
• Fix Version/s: 2.9.5, 2.10.3, 2.11.0
• Component/s: camel-core

Environment

java version "1.6.0_35"
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)

MacOsX 10.7.5

URL: https://svn.apache.org/repos/asf/camel/branches/camel-2.9.x
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1396229
Node Kind: directory
Schedule: normal
Last Changed Author: dkulp
Last Changed Rev: 1396218
Last Changed Date: 2012-10-09 21:36:47 +0200 (Tue, 09 Oct 2012)

• Estimated Complexity: Unknown
• Assignee: Willem Jiang
• Reporter: Gilles Huron
• Created: 14/Oct/12 19:09
• Updated: 23/Sep/13 20:14
• Resolved: 17/Oct/12 13:12

Description

A small JUnit recreation case is attached.
When using embedded split inside a split with parallel processing, threads are getting a wrong exchange (or wrong exchange copy) just after leaving the inner split and returning to the parent split.

In the test case, we split a file by comma in a parent split (Block split), then by line separator in inner split (Line Split).
We expect 2 files in output, each of them containing the respective Blocks.

However, once inner split is complete, each thread is supposed to add a 11th line in the result.txt file saying split is complete.
Bug is that one of the thread ends up with parent split Exchange (copy?) from the other thread, and appends wrong information into the wrong file.

Expected:
---------
(result0.txt)
Block1 Line 1:Status=OK
Block1 Line 2:Status=OK
Block1 Line 0:Status=OK
Block1 Line 4:Status=OK
Block1 Line 3:Status=OK
Block1 Line 8:Status=OK
Block1 Line 5:Status=OK
Block1 Line 6:Status=OK
Block1 Line 7:Status=OK
Block1 Line 9:Status=OK
0 complete

(result1.txt)
Block2 Line 0:Status=OK
Block2 Line 3:Status=OK
Block2 Line 1:Status=OK
Block2 Line 2:Status=OK
Block2 Line 6:Status=OK
Block2 Line 4:Status=OK
Block2 Line 7:Status=OK
Block2 Line 9:Status=OK
Block2 Line 5:Status=OK
Block2 Line 8:Status=OK
1 complete

Actual:
-------
(result0.txt)
Block1 Line 1:Status=OK
Block1 Line 2:Status=OK
Block1 Line 0:Status=OK
Block1 Line 4:Status=OK
Block1 Line 3:Status=OK
Block1 Line 8:Status=OK
Block1 Line 5:Status=OK
Block1 Line 6:Status=OK
Block1 Line 7:Status=OK
Block1 Line 9:Status=OK
0 complete0 complete

(result1.txt)
Block2 Line 0:Status=OK
Block2 Line 3:Status=OK
Block2 Line 1:Status=OK
Block2 Line 2:Status=OK
Block2 Line 6:Status=OK
Block2 Line 4:Status=OK
Block2 Line 7:Status=OK
Block2 Line 9:Status=OK
Block2 Line 5:Status=OK
Block2 Line 8:Status=OK

This issue exist in 2.8.x, and probably in 2.10.x as well.
This is a Splitter/MulticastProcessor or Pipeline issue but not quite familiar with the code, I am having hard time tracking it.

Issue Links

• incorporates: CAMEL-6771 ConcurrentModificationException thrown from inside camel splitter