Details
Task
Resolved
Major
-
- 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 |
Hide
And can you remind me the rationale behind having two sets of threads: one for accepting messages and one for processing them?
Thanks 
Show
Victor NOËL added a comment - Mon, 15 Jun 2015 - 16:49:56 +0200 And can you remind me the rationale behind having two sets of threads: one for accepting messages and one for processing them?
Thanks
Hide
Ok, but why didn't we get just a pool of threads that accept and then directly process? I don't see how it is different… is it?
One difference I see is the fact that acceptor threads wait if there is no available processor threads, and then they drop the messages!
Does it mean we have as a requirement : messages must be dropped if there is no resources available to process them?
I'm trying to clarify the requirements we are trying to achieve independently of the current implementation that seems to have been written by many people at different times
Show
Victor NOËL added a comment - Wed, 17 Jun 2015 - 09:24:13 +0200 Ok, but why didn't we get just a pool of threads that accept and then directly process? I don't see how it is different… is it?
One difference I see is the fact that acceptor threads wait if there is no available processor threads, and then they drop the messages!
Does it mean we have as a requirement : messages must be dropped if there is no resources available to process them?
I'm trying to clarify the requirements we are trying to achieve independently of the current implementation that seems to have been written by many people at different times
| 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 ] |
| Transition | Status Change Time | Execution Times | Last Executer | Last Execution Date | |||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
Question for you Christophe: are the classes in org.ow2.petals.component.framework.monitoring.defect only used to notify in case there is no thread available in the acceptor thread pool?
If the acceptor thread pool is refactored and we can be sure there always be thread available, can we remove the classes in org.ow2.petals.component.framework.monitoring.defect?
Thanks