Petals CDK

Do not drop messages when there is no thread for processors available

Details

  • Type: Improvement Request Improvement Request
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.4.3
  • Fix Version/s: 5.6.0
  • Component/s: None
  • Security Level: Public
  • Description:

    As part of reworking the acceptor thread pool (see PETALSCDK-123), we should not drop messages when there is no thread for processors available.

    Optionally, we should provide different strategies depending on the need (see PETALSCDK-175).

  • Environment:
    -

Issue Links

Depends

Activity

Ascending order - Click to sort in descending order
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:43:49 +0200
Field Original Value New Value
Link This issue depends on PETALSESBCONT-339 [ PETALSESBCONT-339 ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:44:01 +0200
Status New [ 10000 ] Open [ 10002 ]
Priority Blocker [ 1 ]
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:44:17 +0200
Description As part of reworking the acceptor thread pool (see PETALSCDK-123), we should not drop messages when there is no thread for processors available.

This means that first we must take care of the memory consumption of the kernel and DeliveryChannel as their size will grow if the messages are not dropped nor processed.

Optionally, we should provide different strategies depending on the need. 		As part of reworking the acceptor thread pool (see PETALSCDK-123), we should not drop messages when there is no thread for processors available.

This means that first we must take care of the memory consumption of the kernel and DeliveryChannel as their size will grow if the messages are not dropped nor processed (see PETALSESBCONT-339).

Optionally, we should provide different strategies depending on the need.
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:44:43 +0200
Link This issue blocks PETALSCDK-123 [ PETALSCDK-123 ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:51:31 +0200
Priority Blocker [ 1 ] Major [ 3 ]
Victor NOËL made changes - Thu, 2 Jul 2015 - 17:10:36 +0200
Link This issue blocks PETALSDISTRIB-146 [ PETALSDISTRIB-146 ]
Hide
Permalink
Christophe DENEUX added a comment - Mon, 5 Oct 2015 - 15:46:02 +0200

Postponed to 5.5.1 or upper

Show
Christophe DENEUX added a comment - Mon, 5 Oct 2015 - 15:46:02 +0200 Postponed to 5.5.1 or upper
Christophe DENEUX made changes - Mon, 5 Oct 2015 - 15:46:02 +0200
Fix Version/s 5.5.1 [ 10599 ]
Hide
Permalink
Victor NOËL added a comment - Fri, 27 Nov 2015 - 09:52:24 +0100

This was partially solved with PETALSCDK-90: message are not simply dropped, but an error is sent back to notify the consumer.

Still, it would be better not to drop messages by default and introduce various strategies.

Show
Victor NOËL added a comment - Fri, 27 Nov 2015 - 09:52:24 +0100 This was partially solved with PETALSCDK-90: message are not simply dropped, but an error is sent back to notify the consumer. Still, it would be better not to drop messages by default and introduce various strategies.
Victor NOËL made changes - Tue, 8 Dec 2015 - 13:36:17 +0100
Link This issue depends on PETALSCDK-90 [ PETALSCDK-90 ]
Victor NOËL made changes - Wed, 16 Dec 2015 - 16:27:43 +0100
Fix Version/s 5.6.0 [ 10611 ]
Fix Version/s 5.5.1 [ 10599 ]
Christophe DENEUX made changes - Mon, 23 May 2016 - 12:29:45 +0200
Fix Version/s 5.6.1 [ 10641 ]
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:02:45 +0200
Link This issue blocks PETALSCDK-175 [ PETALSCDK-175 ]
Hide
Permalink
Victor NOËL added a comment - Wed, 14 Sep 2016 - 10:04:35 +0200

Updated description: some of the requirements were moved to PETALSCDK-175.

Show
Victor NOËL added a comment - Wed, 14 Sep 2016 - 10:04:35 +0200 Updated description: some of the requirements were moved to PETALSCDK-175.
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:04:35 +0200
Description As part of reworking the acceptor thread pool (see PETALSCDK-123), we should not drop messages when there is no thread for processors available.

This means that first we must take care of the memory consumption of the kernel and DeliveryChannel as their size will grow if the messages are not dropped nor processed (see PETALSESBCONT-339).

Optionally, we should provide different strategies depending on the need. 		As part of reworking the acceptor thread pool (see PETALSCDK-123), we should not drop messages when there is no thread for processors available.

Optionally, we should provide different strategies depending on the need (see PETALSCDK-175).
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:04:49 +0200
Link This issue depends on PETALSESBCONT-339 [ PETALSESBCONT-339 ]
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:04:55 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Victor NOËL added a comment - Wed, 14 Sep 2016 - 10:05:15 +0200

This was solved in 5.6.0.

Show
Victor NOËL added a comment - Wed, 14 Sep 2016 - 10:05:15 +0200 This was solved in 5.6.0.
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:05:15 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 5.6.1 [ 10641 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
6m 13s
1
Victor NOËL
Fri, 19 Jun 2015 - 16:44:01 +0200
Open Open In Progress In Progress
452d 17h 20m
1
Victor NOËL
Wed, 14 Sep 2016 - 10:04:55 +0200
In Progress In Progress Resolved Resolved
20s
1
Victor NOËL
Wed, 14 Sep 2016 - 10:05:15 +0200

People

Dates

  • Created:
    Fri, 19 Jun 2015 - 16:37:48 +0200
    Updated:
    Wed, 14 Sep 2016 - 10:05:15 +0200
    Resolved:
    Wed, 14 Sep 2016 - 10:05:15 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.