On 9/18/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > 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 .... >
Agreed. > Btw, if we introduce thread pools, i'm a bit worried about the effect it > would > have wrt to synchronous calls... > I assume you mean the effect it has when a synchronous processor calls the ThreadProcessor. Ideally I would have liked for the ThreadProcessor to notice that it's getting called in a synchronous way and throw an exception. And I tried implementing that by having the ThreadProcessor.process(Exchange ex) throw an UnsupportedOpperationException.. but that does not work as expected right now. Basically the problem is that async processors along the path will take a sync process call on it and implement it using the async processor api calls. So by the time the call gets to the ThreadProcessor it might look like an async call to it. Perhaps we should forbid async processors from doing this trick. This would make async processors harder to implement since they would have to implement both async and sync versions of their process methods. > 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/ > -- Regards, Hiram Blog: http://hiramchirino.com
