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

Descending order - Click to sort in ascending order
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)
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 - 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
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.
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).
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.
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
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
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
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.
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 - 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
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.
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
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
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
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.

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.