Petals ESB Container

Introduce a mechanism to handle a lot of messages in the DeliveryChannel

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 4.3.0
  • Fix Version/s: 5.4.0
  • Component/s: Persistence
  • Security Level: Public
  • Description:
    Hide

    Currently, when many messages are put in a DeliveryChannel and the component does not take the messages for any reasons, the size of the DeliveryChannel will grow until there is no more memory available.
    Currently, no protection exists to avoid that.

    We should introduce a mechanism for the queue to be flushed on disk: instead of using memory (after a threshold to not impact performance in normal conditions) the messages would be stored on disk.
    Note that persisting to disk using things like memory mapped files is very efficient and writing to disk all the time could be acceptable actually.

    Special attention should be given to the handling of special situations such as JVM crashing and restoring of state after restart.

    Show
    Currently, when many messages are put in a DeliveryChannel and the component does not take the messages for any reasons, the size of the DeliveryChannel will grow until there is no more memory available. Currently, no protection exists to avoid that. We should introduce a mechanism for the queue to be flushed on disk: instead of using memory (after a threshold to not impact performance in normal conditions) the messages would be stored on disk. Note that persisting to disk using things like memory mapped files is very efficient and writing to disk all the time could be acceptable actually. Special attention should be given to the handling of special situations such as JVM crashing and restoring of state after restart.
  • Environment:
    -

Issue Links

Depends

Activity

Ascending order - Click to sort in descending order
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:43:38 +0200
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:43:49 +0200
Link This issue blocks PETALSCDK-135 [ PETALSCDK-135 ]
Christophe DENEUX made changes - Mon, 22 Jun 2015 - 11:40:31 +0200
Summary Introduce persistence in DeliveryChannel Introduce a mechanism to handle a lot of messages in the DeliveryChannel
Description Currently, when many messages are put in a DeliveryChannel and the component does not take the messages, the size of the DeliveryChannel will grow until there is no more memory available.
In order to avoid that, currently, the CDK will drop messages when there is an excess (see PETALSCDK-135).

We should introduce a mechanism for the queue to be persisted: instead of using memory (maybe after a threshold to not impact performance in normal conditions) the messages would be persisted to disk.
Note that persisting to disk using things like memory mapped files is very efficient and writing to disk all the time could be acceptable actually.

Special attention should be given to the handling of special situations such as JVM crashing and restoring of state after restart. 		Currently, when many messages are put in a DeliveryChannel and the component does not take the messages for any reasons, the size of the DeliveryChannel will grow until there is no more memory available.
Currently, no protection exists to avoid that.

We should introduce a mechanism for the queue to be flushed on disk: instead of using memory (after a threshold to not impact performance in normal conditions) the messages would be stored on disk.
Note that persisting to disk using things like memory mapped files is very efficient and writing to disk all the time could be acceptable actually.

Special attention should be given to the handling of special situations such as JVM crashing and restoring of state after restart.
Christophe DENEUX made changes - Mon, 5 Oct 2015 - 15:47:28 +0200
Fix Version/s 5.0.1 [ 10579 ]
Victor NOËL made changes - Tue, 8 Dec 2015 - 13:39:00 +0100
Link This issue blocks PETALSDISTRIB-146 [ PETALSDISTRIB-146 ]
Victor NOËL made changes - Mon, 29 Feb 2016 - 10:11:05 +0100
Link This issue depends on PETALSESBCONT-401 [ PETALSESBCONT-401 ]
Victor NOËL made changes - Mon, 29 Feb 2016 - 10:24:07 +0100
Link This issue depends on PETALSESBCONT-402 [ PETALSESBCONT-402 ]
Christophe DENEUX made changes - Mon, 23 May 2016 - 15:06:21 +0200
Fix Version/s 5.0.2 [ 10661 ]
Fix Version/s 5.0.1 [ 10579 ]
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:01:44 +0200
Link This issue blocks PETALSCDK-175 [ PETALSCDK-175 ]
Victor NOËL made changes - Wed, 14 Sep 2016 - 10:04:49 +0200
Link This issue blocks PETALSCDK-135 [ PETALSCDK-135 ]
Christophe DENEUX made changes - Wed, 21 Sep 2016 - 09:48:33 +0200
Fix Version/s 5.0.2 [ 10661 ]
Fix Version/s 5.0.3 [ 10670 ]
Christophe DENEUX made changes - Thu, 4 Jan 2018 - 10:55:57 +0100
Fix Version/s 5.1.1 [ 10764 ]
Fix Version/s 5.1.0 [ 10670 ]
Christophe DENEUX made changes - Thu, 26 Jul 2018 - 17:20:58 +0200
Assignee Victor NOËL [ vnoel ]
Fix Version/s 5.2.1 [ 10877 ]
Fix Version/s 5.2.0 [ 10764 ]
Christophe DENEUX made changes - Thu, 13 Apr 2023 - 17:03:34 +0200
Fix Version/s 5.4.0 [ 11131 ]
Fix Version/s 5.3.0 [ 10877 ]

People

Dates

  • Created:
    Fri, 19 Jun 2015 - 16:43:26 +0200
    Updated:
    Thu, 13 Apr 2023 - 17:03:34 +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.