I think I found the issue, shareUnitOfWork should create the a new UnitOfWorkProcessor per processing instead of using the last one, as the parent UnitOfWork is different next time. When you using the shareUnitOfWork, the error handler should just get one call. I will commit the fix after running a whole unit tests with my change.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Thursday, January 24, 2013 at 3:21 PM, Willem.Jiang wrote: > Hi, > > I can reproduce this kind of error in the trunk by adding a simple unit test > as you said. > If I remove the shareUnitOfWork setting, the error handler can get expect > numbers messages. > So I just fill a JIRA CAMEL-6005[1] for it. > > [1]https://issues.apache.org/jira/browse/CAMEL-6005 > > Willem > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Possible-bug-with-multicast-shareUnitOfWork-tp5726103p5726113.html > Sent from the Camel - Users mailing list archive at Nabble.com > (http://Nabble.com).
