Hi Antonin, thanks for your answer.
I modified the example slightly. Please see https://github.com/claudiusb/camel-threads-problem-reproducer/commit/9c09201e54513a36e3b1bb6c325689cfe09bdb5f You are right, if the size of the producing thread pool is increased to be greater than the queue size of the consuming executor the RejectedExecutionException is thrown. However, there is still a thing that puzzles me: In my understanding the message is fully processed by "myRoute" if either A) It hands its task to the thread pool which processes it asynchronously xor B) It tries to hand over its task to the thread pool which rejects the execution. In both cases the calling thread should not block longer than a few millis. This is what i observe for the majority of messages. The logs from [1] show messages like 5480 [pool-2-thread-99] INFO c.g.c.c.ThreadsProblemReproducer - Task #9886 took 25 millis to invoke the route 5480 [pool-2-thread-39] INFO c.g.c.c.ThreadsProblemReproducer - Task #9887 took 24 millis to invoke the route 5480 [pool-2-thread-67] INFO c.g.c.c.ThreadsProblemReproducer - Task #9888 took 24 millis to invoke the route At some point the time to call the route increases drastically. Then [1] logs: 10635 [pool-2-thread-47] INFO c.g.c.c.ThreadsProblemReproducer - Task #8036 took 6001 millis to invoke the route 10656 [pool-2-thread-55] INFO c.g.c.c.ThreadsProblemReproducer - Task #8054 took 6017 millis to invoke the route 10656 [pool-2-thread-35] INFO c.g.c.c.ThreadsProblemReproducer - Task #8057 took 6015 millis to invoke the route Can you make sense of that? Best regards Claudius [1] https://github.com/claudiusb/camel-threads-problem-reproducer/blob/master/src/test/java/com/github/claudiusb/camelthreadsproblemreproducer/ThreadsProblemReproducer.java#L104 2015-10-08 22:41 GMT+02:00 Antonin Stefanutti <[email protected]>: > Hi Claudius, > > Using the ProducerTemplate.sendBody [1] method to send a message to the > direct endpoint actually creates a UnitOfWorkProducer instance that blocks > the caller thread until the unit of work has completed [2]. So even if your > route contains some asynchronous processing through the threads DSL, the > caller thread will block until the message is fully processed. > > As your producing executor service thread pool size is equals to the task > queue size of your consuming executor, and given the call to sendBody is > synchronous, no rejection occurs. > > [1] > https://github.com/claudiusb/camel-threads-problem-reproducer/blob/master/src/test/java/com/github/claudiusb/camelthreadsproblemreproducer/ThreadsProblemReproducer.java#L103 > > [2] > https://github.com/apache/camel/blob/camel-2.14.0/camel-core/src/main/java/org/apache/camel/processor/UnitOfWorkProducer.java#L72 > > Antonin > > > On 07 Oct 2015, at 19:35, Claudius B <[email protected]> > wrote: > > > > Hi Camel community, > > > > I was trying to turn a route into asynchronous processing to cause it to > > return immediately using the threads API ( > http://camel.apache.org/async.html). > > When the route, more accurately the routes thread pool, cannot process > more > > tasks, those should be rejected with an exception (Abort) - which is not > > happening. > > > > The unexpected behaviour is shown and further explained in this unit > test: > > https://github.com/claudiusb/camel-threads-problem-reproducer > > > > I would be very glad if someone could take a look on this and explain to > me > > what is happening, if im using the API in the wrong way or if this might > be > > a problem in Camel. > > > > Best regards > > Claudius > >
