Petals CDK

If no more message exchange processor thread is available, new incoming message exchange should be enqueued instead of to be rejected

Details

  • Type: Improvement Request Improvement Request
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.1.3, 5.2.0
  • Fix Version/s: 5.1.4, 5.3.0
  • Component/s: runtime
  • Security Level: Public
  • Description:
    Hide

    To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

    To prevent resources consumption, the queue size can be customized through the component parameter 'processor-queue-size'. This parameter can be hot-set.

    Show
    To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected. To prevent resources consumption, the queue size can be customized through the component parameter 'processor-queue-size'. This parameter can be hot-set.
  • Environment:
    -

Issue Links

Depends
 
Duplicate
 

Activity

Ascending order - Click to sort in descending order
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 08:50:42 +0200
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Assignee Mathieu Carrolle [ mcarrolle ] Christophe DENEUX [ cdeneux ]
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 08:50:48 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 08:50:58 +0200
Affects Version/s 5.1.3 [ 10284 ]
Hide
Permalink
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 08:52:29 +0200

As the ArrayBlockingQueue used as queue of the ThreadPoolExecutor of message exchange processor can not be resized, the parameter 'processor-queue-size' can not be hot-set. Description updated.

Show
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 08:52:29 +0200 As the ArrayBlockingQueue used as queue of the ThreadPoolExecutor of message exchange processor can not be resized, the parameter 'processor-queue-size' can not be hot-set. Description updated.
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 08:52:55 +0200
Description To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

To prevent resources consumption, the queue size can be customized through the component parameter {{'processor-queue-size'}}. This parameter can be hot-set. 		To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

To prevent resources consumption, the queue size can be customized through the component parameter {{'processor-queue-size'}}.- This parameter can be hot-set.-
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 08:53:31 +0200
Description To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

To prevent resources consumption, the queue size can be customized through the component parameter {{'processor-queue-size'}}.- This parameter can be hot-set.- 		To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

To prevent resources consumption, the queue size can be customized through the component parameter {{'processor-queue-size'}}. -This parameter can be hot-set.-
Hide
Permalink
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 09:22:10 +0200

Fixed in branch petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 09:22:10 +0200 Fixed in branch petals-enterprise-3.1.x
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 09:22:10 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 5.1.4 [ 10328 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 09:22:19 +0200

To merge in trunk

Show
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 09:22:19 +0200 To merge in trunk
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 09:22:19 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 09:22:25 +0200
Fix Version/s 5.3.0 [ 10338 ]
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 10:00:16 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 10:58:52 +0200

Merged in trunk

Show
Christophe DENEUX added a comment - Fri, 20 Apr 2012 - 10:58:52 +0200 Merged in trunk
Christophe DENEUX made changes - Fri, 20 Apr 2012 - 10:58:52 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Thu, 10 May 2012 - 11:14:50 +0200

Reopen because the ThreadPoolExecutor provided by the JVM prefers to enqueue message rather than creating extra threads.

As the NMR of the Petals Kernel already includes a queue, we can use it as overflowing queue with the following changes:

  • the queue size should be customizable at container level (PETALSESBCONT-190),
  • when the queue is full, the enqueuing should wait a moment before to fail (PETALSESBCONT-191),
  • a retry policy should be added when accepting message exchange to prevent message lost when an exhaustion occurs.
Show
Christophe DENEUX added a comment - Thu, 10 May 2012 - 11:14:50 +0200 Reopen because the ThreadPoolExecutor provided by the JVM prefers to enqueue message rather than creating extra threads. As the NMR of the Petals Kernel already includes a queue, we can use it as overflowing queue with the following changes:
  • the queue size should be customizable at container level (PETALSESBCONT-190),
  • when the queue is full, the enqueuing should wait a moment before to fail (PETALSESBCONT-191),
  • a retry policy should be added when accepting message exchange to prevent message lost when an exhaustion occurs.
Christophe DENEUX made changes - Thu, 10 May 2012 - 11:14:50 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Thu, 10 May 2012 - 11:15:16 +0200
Link This issue depends on PETALSESBCONT-190 [ PETALSESBCONT-190 ]
Christophe DENEUX made changes - Thu, 10 May 2012 - 11:15:16 +0200
Link This issue depends on PETALSESBCONT-191 [ PETALSESBCONT-191 ]
Christophe DENEUX made changes - Thu, 10 May 2012 - 13:25:07 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Christophe DENEUX added a comment - Thu, 10 May 2012 - 13:25:39 +0200

Previous fixed removed from trunk.
Retry policy added in trunk

Show
Christophe DENEUX added a comment - Thu, 10 May 2012 - 13:25:39 +0200 Previous fixed removed from trunk. Retry policy added in trunk
Christophe DENEUX made changes - Thu, 10 May 2012 - 13:25:39 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Thu, 10 May 2012 - 15:40:54 +0200

Backported in branch petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Thu, 10 May 2012 - 15:40:54 +0200 Backported in branch petals-enterprise-3.1.x
Hide
Permalink
Christophe DENEUX added a comment - Tue, 15 May 2012 - 16:59:56 +0200

Reopen because few messages are lost.

Show
Christophe DENEUX added a comment - Tue, 15 May 2012 - 16:59:56 +0200 Reopen because few messages are lost.
Christophe DENEUX made changes - Tue, 15 May 2012 - 16:59:56 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Tue, 15 May 2012 - 17:00:01 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Christophe DENEUX added a comment - Tue, 15 May 2012 - 17:02:46 +0200

Fixed in trunk

Show
Christophe DENEUX added a comment - Tue, 15 May 2012 - 17:02:46 +0200 Fixed in trunk
Christophe DENEUX made changes - Tue, 15 May 2012 - 17:02:46 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Tue, 15 May 2012 - 17:03:17 +0200

Backport the fix of loss of few messages into the branch petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Tue, 15 May 2012 - 17:03:17 +0200 Backport the fix of loss of few messages into the branch petals-enterprise-3.1.x
Christophe DENEUX made changes - Tue, 15 May 2012 - 17:03:17 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Tue, 15 May 2012 - 17:05:11 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Christophe DENEUX added a comment - Tue, 15 May 2012 - 17:05:34 +0200

Backported in branch petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Tue, 15 May 2012 - 17:05:34 +0200 Backported in branch petals-enterprise-3.1.x
Christophe DENEUX made changes - Tue, 15 May 2012 - 17:05:34 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Wed, 16 May 2012 - 15:11:18 +0200 - edited

Reopen because the AsyncMessageManager does not correctly handle pool exhaustion when cleaning expired message exchanges.

Show
Christophe DENEUX added a comment - Wed, 16 May 2012 - 15:11:18 +0200 - edited Reopen because the AsyncMessageManager does not correctly handle pool exhaustion when cleaning expired message exchanges.
Christophe DENEUX made changes - Wed, 16 May 2012 - 15:11:18 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Mon, 21 May 2012 - 15:32:23 +0200

After investigation, the map AsyncMessageManager.originalAsynchronousContext contains, with our test case, only one entry for all message exchanges sent asynchronously. When the first timed-out message exchange is detected, the entry is removed, and other expired async messages are no more considered as asynchronous message (they income through JBIListener.onJBIMessage instead of JBIListener.onExpiredAsyncJBIMessage.
Utility of two maps of AsyncMessageManager must be reviewed (PETALSCDK-100).

Show
Christophe DENEUX added a comment - Mon, 21 May 2012 - 15:32:23 +0200 After investigation, the map AsyncMessageManager.originalAsynchronousContext contains, with our test case, only one entry for all message exchanges sent asynchronously. When the first timed-out message exchange is detected, the entry is removed, and other expired async messages are no more considered as asynchronous message (they income through JBIListener.onJBIMessage instead of JBIListener.onExpiredAsyncJBIMessage. Utility of two maps of AsyncMessageManager must be reviewed (PETALSCDK-100).
Christophe DENEUX made changes - Mon, 21 May 2012 - 15:32:49 +0200
Link This issue depends on PETALSCDK-100 [ PETALSCDK-100 ]
Christophe DENEUX made changes - Mon, 21 May 2012 - 15:53:20 +0200
Link This issue is duplicated by PETALSCDK-89 [ PETALSCDK-89 ]
Christophe DENEUX made changes - Fri, 25 May 2012 - 11:43:32 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Christophe DENEUX added a comment - Fri, 25 May 2012 - 11:44:40 +0200

Asynchronous context management and expiration of asynchronous context has been reworked in trunk.

Show
Christophe DENEUX added a comment - Fri, 25 May 2012 - 11:44:40 +0200 Asynchronous context management and expiration of asynchronous context has been reworked in trunk.
Christophe DENEUX made changes - Fri, 25 May 2012 - 11:44:40 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Fri, 25 May 2012 - 11:45:34 +0200

Backport asynchronous message management reworking in branch petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Fri, 25 May 2012 - 11:45:34 +0200 Backport asynchronous message management reworking in branch petals-enterprise-3.1.x
Christophe DENEUX made changes - Fri, 25 May 2012 - 11:45:34 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Sat, 26 May 2012 - 08:46:17 +0200
Description To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

To prevent resources consumption, the queue size can be customized through the component parameter {{'processor-queue-size'}}. -This parameter can be hot-set.- 		To accept bursts of message exchanges (for example generated by diffusion/aggregation component), new incoming message exchange should be enqueued instead of to be rejected.

-To prevent resources consumption, the queue size can be customized through the component parameter {{'processor-queue-size'}}.- -This parameter can be hot-set.-
Hide
Permalink
Christophe DENEUX added a comment - Sat, 26 May 2012 - 08:47:31 +0200 - edited

A regression has been introduced in trunk by commit svn#32623 and was fixed by svn#32628 (thanks to integration tests)

Show
Christophe DENEUX added a comment - Sat, 26 May 2012 - 08:47:31 +0200 - edited A regression has been introduced in trunk by commit svn#32623 and was fixed by svn#32628 (thanks to integration tests)
Hide
Permalink
Christophe DENEUX added a comment - Thu, 31 May 2012 - 12:50:40 +0200

Reworks of asynchronous context management and expiration of asynchronous context have been backported in branch petals-enterprise-3.1.x (including the small regression fix)

Show
Christophe DENEUX added a comment - Thu, 31 May 2012 - 12:50:40 +0200 Reworks of asynchronous context management and expiration of asynchronous context have been backported in branch petals-enterprise-3.1.x (including the small regression fix)
Christophe DENEUX made changes - Thu, 31 May 2012 - 12:50:49 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Christophe DENEUX made changes - Thu, 31 May 2012 - 12:50:54 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
15h 21m
1
Christophe DENEUX
Fri, 20 Apr 2012 - 08:50:42 +0200
Open Open In Progress In Progress
6s
1
Christophe DENEUX
Fri, 20 Apr 2012 - 08:50:48 +0200
In Progress In Progress Resolved Resolved
31m 22s
1
Christophe DENEUX
Fri, 20 Apr 2012 - 09:22:10 +0200
Resolved Resolved Open Open
9s
1
Christophe DENEUX
Fri, 20 Apr 2012 - 09:22:19 +0200
Open Open In Progress In Progress
37m 57s
1
Christophe DENEUX
Fri, 20 Apr 2012 - 10:00:16 +0200
In Progress In Progress Resolved Resolved
58m 36s
1
Christophe DENEUX
Fri, 20 Apr 2012 - 10:58:52 +0200
Resolved Resolved Open Open
20d 15m
1
Christophe DENEUX
Thu, 10 May 2012 - 11:14:50 +0200
Open Open In Progress In Progress
2h 10m
1
Christophe DENEUX
Thu, 10 May 2012 - 13:25:07 +0200
In Progress In Progress Resolved Resolved
32s
1
Christophe DENEUX
Thu, 10 May 2012 - 13:25:39 +0200
Resolved Resolved Open Open
5d 3h 34m
1
Christophe DENEUX
Tue, 15 May 2012 - 16:59:56 +0200
Open Open In Progress In Progress
5s
1
Christophe DENEUX
Tue, 15 May 2012 - 17:00:01 +0200
In Progress In Progress Resolved Resolved
2m 45s
1
Christophe DENEUX
Tue, 15 May 2012 - 17:02:46 +0200
Resolved Resolved Open Open
31s
1
Christophe DENEUX
Tue, 15 May 2012 - 17:03:17 +0200
Open Open In Progress In Progress
1m 54s
1
Christophe DENEUX
Tue, 15 May 2012 - 17:05:11 +0200
In Progress In Progress Resolved Resolved
23s
1
Christophe DENEUX
Tue, 15 May 2012 - 17:05:34 +0200
Resolved Resolved Open Open
22h 5m
1
Christophe DENEUX
Wed, 16 May 2012 - 15:11:18 +0200
Open Open In Progress In Progress
8d 20h 32m
1
Christophe DENEUX
Fri, 25 May 2012 - 11:43:32 +0200
In Progress In Progress Resolved Resolved
1m 8s
1
Christophe DENEUX
Fri, 25 May 2012 - 11:44:40 +0200
Resolved Resolved Open Open
54s
1
Christophe DENEUX
Fri, 25 May 2012 - 11:45:34 +0200
Open Open In Progress In Progress
6d 1h 5m
1
Christophe DENEUX
Thu, 31 May 2012 - 12:50:49 +0200
In Progress In Progress Resolved Resolved
5s
1
Christophe DENEUX
Thu, 31 May 2012 - 12:50:54 +0200

People

Dates

  • Created:
    Thu, 19 Apr 2012 - 17:29:28 +0200
    Updated:
    Thu, 31 May 2012 - 12:50:54 +0200
    Resolved:
    Thu, 31 May 2012 - 12:50:54 +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.