Thanks for the pointer. Sounds like the thread pools are per camel context, which usually equates to per route. If there was a connector/producer that had a very high frequency of exchanges routed however other things in the route processed data more slowly than the producer, I can see there being a potential issue depending on how the thread pool queue is setup. Does camel have anything to mitigate this? maybe a disk backed queuing mechanism, a upper bounds on the queue with blocking until there's space, or perhaps is the best option to use an external solution, such as kafka?
On Mon, Sep 4, 2023 at 2:16 AM ski n <raymondmees...@gmail.com> wrote: > The starting doc is the following: > > https://camel.apache.org/manual/threading-model.html > > If you still some questions or missing some stuff you can ask them here of > course. > > Raymond > > On Sun, Sep 3, 2023 at 8:42 PM Alex O'Ree <alexo...@apache.org> wrote: > > > Under the hood, does camel allocate thread pools specific to each route > or > > is it more of a per processor/connector setup or is it one big shared > > thread pool for the whole application? > > > > Is there anywhere i can find discussions on this topic or documentation > > that describes the general thread model used by camel? > > > > Likewise with camel clustering and scaling... is there docs anywhere that > > describes how this works? > > >
