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
org.apache.camel.spring.pollingconsumer.SpringScheduledPollConsumerScheduler
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 :/).
I hacked the code to make it explicitly look up the reference, making
the taskScheduler object a Spring-provided bean, and it seemed to work…
But then we realized that the thread is used for the whole route, and
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
--
Tomasz Melcer
