> But then we realized that the thread is used for the whole route, and
> not just for the consumer.
Did you try to separate your consumer and the route with SEDA?
Like:
from(YourConsumerHere)
.to("seda://next-step");
from("seda://next-step")
.process(NextYourStepsHere);
It will use another thread for SEDA consumer.
On Thu, 2021-07-22 at 15:01 +0200, Tomasz Melcer wrote:
> On 7/21/21 3:23 PM, Tomasz Melcer wrote:
> > On 7/20/21 2:59 PM, Zoran Regvart wrote:
> > > Perhaps you could try using a custom executor service
> > > (`scheduledExecutorService`) with a fixed number of threads?
> >
> > […]
> Well, so we've tested it and, as documentation states here [1]
>
> > Notice: If using a custom scheduler then the options for
> > initialDelay, useFixedDelay, timeUnit and scheduledExecutorService
> > may not be in use.
>
> Using scheduler=spring is apparently custom enough for this condition
> to
> be true.
>
> After studying the
> class I started thinking that it might be possible to instead share the
> thread pool inside, while keeping this class as the custom scheduler.
>
> I tried using `&scheduler.taskScheduler=#myPool` in the URL only to
> realize that somehow Camel just didn't want to locate the object. Camel
> 2.x just doesn't want to resolve named references to `scheduler.*`
> parameters (and we're tied to Camel 2.x for now due to required Java 8
> compatibility :/).
>
> the taskScheduler object a Spring-provided bean, and it seemed to work…
> not just for the consumer. This is not something we want, as in case of
> later redelivery, the thread is not freed to allow other queries to
> happen.
>
> Hence we're looking for a different approach right now.
>
>
> [1]
> https://camel.apache.org/components/latest/eips/polling-consumer.html
>
>
--
_________________
Vyacheslav Boyko,
mailto:[email protected]
