I think we should keep the seda component somehow, but change itssemantic (and name) so that it becomes a "in memory queue", like JMS without persistence and all. I think it still can be quite handy for unit testing, demos, etc ....
Btw, if we introduce thread pools, i'm a bit worried about the effect it would have wrt to synchronous calls... On 9/18/07, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > FYI: I've opened and started to work on > http://issues.apache.org/activemq/browse/CAMEL-149 > to add that .thread() method. > > > On 9/1/07, Brian McCallister <[EMAIL PROTECTED]> wrote: > > * Corollary -- the seda component should go away and be replaced with > > a thread pool policy. This should be done as a policy/interceptor as > > it is not an endpoint unto itself, it just controls how messages make > > their way between. Given: > > > > from("file:foo").threadPool(10).to("wombat:nugget") > > or > > from("file:foo").threads(10).to("wombat:nugget") > > > > The file component would push to a blocking queue which ten threads > > pull from and pass on to "wombat:nugget" This provides clear control > > over how threads are allocated and used to the developer -- a Good > > Thing(r). > > > > -- > > > > More to say, but need to run and this email has been gathering for > > too long so will send it out incomplete. > > > > -Brian > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
