Petals CDK

Rework the Acceptor/Processor thread pools

Details

  • Type: Task Task
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.4.2
  • Fix Version/s: 5.6.0
  • Component/s: runtime
  • Security Level: Public
  • Description:
    Hide

    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
    Show
    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

Activity

Christophe DENEUX made changes - Mon, 16 Mar 2015 - 11:46:00 +0100
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.
Victor NOËL made changes - Mon, 16 Mar 2015 - 12:02:40 +0100
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Tue, 26 May 2015 - 16:37:20 +0200
Link This issue blocks PETALSCDK-90 [ PETALSCDK-90 ]
Victor NOËL made changes - Tue, 26 May 2015 - 16:37:46 +0200
Link This issue blocks PETALSCDK-94 [ PETALSCDK-94 ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:44:43 +0200
Link This issue depends on PETALSCDK-135 [ PETALSCDK-135 ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:50:22 +0200
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 PETALSCDK-135, the goal is to rewrite the Acceptor/Processor message handling.

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 PETALSCDK-135 is fixed).
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:51:15 +0200
Status New [ 10000 ] Open [ 10002 ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:59:37 +0200
Link This issue blocks PETALSCDK-94 [ PETALSCDK-94 ]
Christophe DENEUX made changes - Mon, 5 Oct 2015 - 15:42:53 +0200
Fix Version/s 5.5.1 [ 10599 ]
Fix Version/s 5.5.0 [ 10406 ]
Christophe DENEUX made changes - Wed, 28 Oct 2015 - 12:52:40 +0100
Link This issue blocks PETALSDISTRIB-181 [ PETALSDISTRIB-181 ]
Victor NOËL made changes - Thu, 5 Nov 2015 - 09:03:10 +0100
Link This issue blocks PETALSDISTRIB-181 [ PETALSDISTRIB-181 ]
Victor NOËL made changes - Wed, 16 Dec 2015 - 16:27:42 +0100
Fix Version/s 5.6.0 [ 10611 ]
Fix Version/s 5.5.1 [ 10599 ]
Victor NOËL made changes - Thu, 11 Feb 2016 - 15:24:53 +0100
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 PETALSCDK-135, the goal is to rewrite the Acceptor/Processor message handling.

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 PETALSCDK-135 is fixed).
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 are notified in case there is an available processor thread so that they do not wait for nothing
Victor NOËL made changes - Fri, 12 Feb 2016 - 12:11:00 +0100
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 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 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 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
Victor NOËL made changes - Fri, 12 Feb 2016 - 16:17:13 +0100
Link This issue blocks PETALSESBCLI-143 [ PETALSESBCLI-143 ]
Victor NOËL made changes - Fri, 12 Feb 2016 - 17:08:48 +0100
Link This issue blocks PETALSESBCONT-396 [ PETALSESBCONT-396 ]
Victor NOËL made changes - Fri, 12 Feb 2016 - 17:09:25 +0100
Link This issue blocks PETALSCDK-162 [ PETALSCDK-162 ]
Victor NOËL made changes - Mon, 15 Feb 2016 - 10:42:12 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Mon, 15 Feb 2016 - 10:42:19 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]

People

Dates

  • Created:
    Mon, 16 Mar 2015 - 11:45:20 +0100
    Updated:
    Mon, 15 Feb 2016 - 10:42:19 +0100
    Resolved:
    Mon, 15 Feb 2016 - 10:42:19 +0100