Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of baris@acar.org.uk designates
 74.125.82.178 as permitted sender)
References: 
 <CADE2u7O7yOJN0gnYLkrM4YUOF5=5MiKHYQNTVnwG10zaNoyUQA@mail.gmail.com>
 <CAGB5yNmAR1pptVvQSpwqACGSDxD0NDtUVbcx+q0bQJbBD6A+5A@mail.gmail.com>
 <31CD4B29-4F5F-474F-83D1-AFC425E6A668@acar.org.uk>
 <CAGB5yNnZ=91WVb_d8+1NwqKqT7jXgKUKOBWfEjVFhe-eoUS8qA@mail.gmail.com>
 <CAGB5yNmQF-e1BT2SvtYr3rATyiQ=5waZz0LvLrAim7e5djaj1A@mail.gmail.com>
In-Reply-To: 
 <CAGB5yNmQF-e1BT2SvtYr3rATyiQ=5waZz0LvLrAim7e5djaj1A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8
Message-Id: <102DA727-0955-4DAD-A662-7504CF6A4867@acar.org.uk>
Cc: "users@camel.apache.org" <users@camel.apache.org>
From: Baris Acar <baris@acar.org.uk>
Subject: Re: Aggregator lock
Date: Wed, 18 Sep 2013 17:32:25 +0100
To: "users@camel.apache.org" <users@camel.apache.org>

Thanks Claus. It is still verbose/error prone - I have to repeat it every ti=
me I use such a processor (verbose) and I have to remember to do it (error p=
rone). And that assumes I *know* that I have to do it in the first place - I=
 don't know how I can tell whether a given processor holds a lock around all=
 downstream processing without detailed inspection of the source.=20

Here's an extreme example to illustrate what I mean:

from("direct:a")
  .threads(5)       // set up a thread pool
  .bean(dostuff)    // excellent, stuff is done in parallel on 5 threads - h=
appy days.
  .aggregate(...)   // I'm a good dev and remembered to RE-introduce a threa=
dpool using executorService, otherwise camel will not execute any of the fol=
lowing in the thread pool I made above.=20
    .executorService(...)
  .multicast(...)   // does multicast() acquire a big lock on downstream wor=
k just like aggregate?
    .executorService(...)  // (...better process downstream on another execu=
tor service to be sure)
  .delay(1000)      // maybe delay will lock too? Add another executorServic=
e!
    .executorService(...)
  .log("got a msg") // how about now? Maybe log() locks all downstream threa=
ds too just like aggregate! Who knows?
    .threads(5)     // shall I just reintroduce the threadpool on every othe=
r line, just to be absolutely sure?
  .someOtherBuiltInCamelProcessor()
    .threads(5)     // ... if not, how can I know *when* I need to reintrodu=
ce it? Camel may arbitrarily lock me out!
  // etc

How can I reason about my system's behaviour without knowing which parts of m=
y code will be executed under a seemingly arbitrary mutual exclusion lock? W=
hich processors take this lock, and why?

Again, thanks for your time.=20

Bar=C4=B1=C5=9F=