The acceptor thread pool is a fixed size list of threads. Each thread accepts messages from the delivery channel before to give them to the message processors.
In relation with PETALSCDK-135, the goal is to rewrite the Acceptor/Processor message handling.
The final result should be something like this:
Acceptor threads that dies are recreated
There is only one acceptor thread by default (there should be no need for more, but who knows... so we keep the pool)
There is a pool for the processor threads (and we remove the pool of processors) (and the CDK parameter message-processor-max-pool-size is removed)
Acceptor that are waiting in retry stop waiting as soon as a new processor is available
The acceptor thread pool is a fixed size list of threads. Each thread accepts messages from the delivery channel before to give them to the message processors.
In relation with PETALSCDK-135, the goal is to rewrite the Acceptor/Processor message handling.
The final result should be something like this:
Acceptor threads that dies are recreated
There is only one acceptor thread by default (there should be no need for more, but who knows... so we keep the pool)
There is a pool for the processor threads (and we remove the pool of processors) (and the CDK parameter message-processor-max-pool-size is removed)
Acceptor that are waiting in retry stop waiting as soon as a new processor is available
Environment:
-
Issue Links
Depends
This issue depends on:
PETALSCDK-135
Do not drop messages when there is no thread for processors available
This issue blocks:
PETALSCDK-90
No response to the service consumer if the message exchange is rejected by processors
PETALSCDK-162
Potential starvation of acceptor threads