If the number of threads truly isn't an issue, you can at least reduce the number of SEDA queues to the number of routes by using the concurrentConsumers option.
Is the reason for the 200 routes solely because of having 200 semi-dynamically-determined endpoints? Are messages from these 200 endpoints sufficiently distinct that you require 200 matching processors? Or could you feed these 200 endpoints into a single queue with a large concurrentConsumers setting? Don On Fri, Jun 29, 2012 at 6:17 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Fri, Jun 29, 2012 at 11:15 AM, Henryk Konsek <hekon...@gmail.com> wrote: >>> Sounds like you echo my concerns Henryk. Was wondering if there is any kind >>> of metrics on the overhead of SEDA queues. I have concerns similar to those >>> outlined by Henryk >> >> My concerns don't relate to the performance since the quantity of >> resources needed to handle 1000 queues is linear. You just got more >> threads running on the JVM. >> >> My concerns rather affects the complexity of design of this kind of >> solutions (thousands of similar SEDA queues in single Camel context). >> > > Yeah I would reconsider the design. > > > >> -- >> Henryk Konsek >> http://henryk-konsek.blogspot.com > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
