Details
-
- Environment:
- -
Issue Links
| Depends | ||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 5.5.0 [ 10406 ] | |
| Priority | Major [ 3 ] | |
| Description |
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.
The acceptor thread pool could be replaced usefully by a Java {{ExecutorService}} where acceptor processing is the task to execute: * on startup, the component launches a number of tasks equals to the core size of the thread pool, * when a task ends, it launches another one, * when increasing the thread pool size (through JMX), the thread pool is reconfigured and new tasks are submitted, * when decreasing the thread pool size (through JMX), the thread pool is reconfigured. The number of threads will be decreased automatically when processing messages. |
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.
The acceptor thread pool could be replaced usefully by a Java {{ExecutorService}} where acceptor processing is the task to execute: * on startup, the component launches a number of tasks equals to the core size of the thread pool, * when a task ends, the ending task launches another one just before to end, * when increasing the thread pool size (through JMX), the thread pool is reconfigured and new tasks are submitted, * when decreasing the thread pool size (through JMX), the thread pool is reconfigured. The number of threads will be decreased automatically when processing messages. |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Link |
This issue blocks |
| Link |
This issue blocks |
| Link |
This issue depends on |
| Summary | Rework the acceptor thread pool | Rework the Acceptor/Processor thread pools |
| Description |
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.
The acceptor thread pool could be replaced usefully by a Java {{ExecutorService}} where acceptor processing is the task to execute: * on startup, the component launches a number of tasks equals to the core size of the thread pool, * when a task ends, the ending task launches another one just before to end, * when increasing the thread pool size (through JMX), the thread pool is reconfigured and new tasks are submitted, * when decreasing the thread pool size (through JMX), the thread pool is reconfigured. The number of threads will be decreased automatically when processing messages. |
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 The final result should be something like this: - A certain number of processor thread are responsible of directly take a message when they have nothing to do. - The acceptor threads are removed (no need for them once |
| Status | New [ 10000 ] | Open [ 10002 ] |
| Link |
This issue blocks |
| Fix Version/s | 5.5.1 [ 10599 ] | |
| Fix Version/s | 5.5.0 [ 10406 ] |
| Link | This issue blocks PETALSDISTRIB-181 [ PETALSDISTRIB-181 ] |
| Link | This issue blocks PETALSDISTRIB-181 [ PETALSDISTRIB-181 ] |
| Fix Version/s | 5.6.0 [ 10611 ] | |
| Fix Version/s | 5.5.1 [ 10599 ] |
| Description |
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 The final result should be something like this: - A certain number of processor thread are responsible of directly take a message when they have nothing to do. - The acceptor threads are removed (no need for them once |
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 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 are notified in case there is an available processor thread so that they do not wait for nothing |
| Description |
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 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 are notified in case there is an available processor thread so that they do not wait for nothing |
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 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 |
| Link |
This issue blocks |
| Link |
This issue blocks |
| Link |
This issue blocks |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Resolution | Fixed [ 1 ] |