Petals CDK

No response to the service consumer if the message exchange is rejected by processors

Details

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

    If no more message exchange processors is available or no thread is available to execute a message exchange processor, no response is sent to the service consumer. The service consumer will get a time-out as error, that is not the real error.

  • Environment:
    -

Issue Links

Activity

Christophe DENEUX made changes - Thu, 5 Apr 2012 - 14:49:45 +0200
Field Original Value New Value
Link This issue depends on PETALSCDK-88 [ PETALSCDK-88 ]
Christophe DENEUX made changes - Thu, 5 Apr 2012 - 14:50:13 +0200
Assignee Mathieu Carrolle [ mcarrolle ]
Fix Version/s 5.3.0 [ 10338 ]
Priority Major [ 3 ]
Christophe DENEUX made changes - Thu, 12 Apr 2012 - 17:17:53 +0200
Summary No response to the service consumer is the message exchange is rejected by processors No response to the service consumer if the message exchange is rejected by processors
Hide
Christophe DENEUX added a comment - Mon, 21 May 2012 - 16:10:25 +0200

Since PETALSCDK-91, a retry policy has been introduced at message exchange acceptor level. If no message exchange processor is available, a rety is done. But when the retry policy ends, the message exchange will be lost.
So to avoid to lose the message exchange, two ways exist:

  1. an error should be returned to the consumer,
  2. the acceptor thread could be used to run the message exchange processor, and so, the consumer will be indirectly slowed down.
    The better way is #2
Show
Christophe DENEUX added a comment - Mon, 21 May 2012 - 16:10:25 +0200 Since PETALSCDK-91, a retry policy has been introduced at message exchange acceptor level. If no message exchange processor is available, a rety is done. But when the retry policy ends, the message exchange will be lost. So to avoid to lose the message exchange, two ways exist:
  1. an error should be returned to the consumer,
  2. the acceptor thread could be used to run the message exchange processor, and so, the consumer will be indirectly slowed down. The better way is #2
Hide
Christophe DENEUX added a comment - Thu, 31 May 2012 - 17:27:12 +0200

Delayed to 5.4.0

Show
Christophe DENEUX added a comment - Thu, 31 May 2012 - 17:27:12 +0200 Delayed to 5.4.0
Christophe DENEUX made changes - Thu, 31 May 2012 - 17:27:12 +0200
Fix Version/s 5.4.0 [ 10362 ]
Fix Version/s 5.3.0 [ 10338 ]
Christophe DENEUX made changes - Tue, 24 Sep 2013 - 09:27:28 +0200
Fix Version/s VNext [ 10406 ]
Fix Version/s 5.4.0 [ 10362 ]
Victor NOËL made changes - Tue, 26 May 2015 - 16:37:19 +0200
Link This issue depends on PETALSCDK-123 [ PETALSCDK-123 ]
Victor NOËL made changes - Fri, 19 Jun 2015 - 16:51:02 +0200
Status New [ 10000 ] Open [ 10002 ]
Assignee Victor NOËL [ vnoel ]
Hide
Victor NOËL added a comment - Fri, 19 Jun 2015 - 16:57:24 +0200

Once PETALSCDK-123 is fixed, we should introduce an alternative strategy (as stated in PETALSCDK-135) where after a certain (configurable) time, an error is set on the exchange with a petals-specific exception whose semantics is that there is no resource available to process the message.

Show
Victor NOËL added a comment - Fri, 19 Jun 2015 - 16:57:24 +0200 Once PETALSCDK-123 is fixed, we should introduce an alternative strategy (as stated in PETALSCDK-135) where after a certain (configurable) time, an error is set on the exchange with a petals-specific exception whose semantics is that there is no resource available to process the message.
Victor NOËL made changes - Wed, 23 Sep 2015 - 15:05:32 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Wed, 23 Sep 2015 - 15:05:42 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Victor NOËL added a comment - Thu, 29 Oct 2015 - 09:16:37 +0100

Reopened: it wasn't actually fixed, there was an error in bound checks and the message sending was never triggered when the max number of try was reached.

Show
Victor NOËL added a comment - Thu, 29 Oct 2015 - 09:16:37 +0100 Reopened: it wasn't actually fixed, there was an error in bound checks and the message sending was never triggered when the max number of try was reached.
Victor NOËL made changes - Thu, 29 Oct 2015 - 09:16:37 +0100
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Victor NOËL made changes - Thu, 29 Oct 2015 - 09:16:49 +0100
Fix Version/s 5.5.1 [ 10599 ]
Fix Version/s 5.5.0 [ 10406 ]
Victor NOËL made changes - Thu, 29 Oct 2015 - 17:40:35 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Victor NOËL added a comment - Thu, 29 Oct 2015 - 17:40:44 +0100

Resolved finally for 5.5.1

Show
Victor NOËL added a comment - Thu, 29 Oct 2015 - 17:40:44 +0100 Resolved finally for 5.5.1
Victor NOËL made changes - Thu, 29 Oct 2015 - 17:40:44 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Victor NOËL made changes - Tue, 8 Dec 2015 - 13:36:18 +0100
Link This issue blocks PETALSCDK-135 [ PETALSCDK-135 ]
Victor NOËL made changes - Tue, 8 Dec 2015 - 13:38:59 +0100
Link This issue blocks PETALSDISTRIB-146 [ PETALSDISTRIB-146 ]
Victor NOËL made changes - Wed, 16 Dec 2015 - 16:27:47 +0100
Fix Version/s 5.6.0 [ 10611 ]
Fix Version/s 5.5.1 [ 10599 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
1170d 2h 1m
1
Victor NOËL
Fri, 19 Jun 2015 - 16:51:02 +0200
Open Open In Progress In Progress
95d 22h 14m
1
Victor NOËL
Wed, 23 Sep 2015 - 15:05:32 +0200
In Progress In Progress Resolved Resolved
10s
1
Victor NOËL
Wed, 23 Sep 2015 - 15:05:42 +0200
Resolved Resolved Open Open
35d 19h 10m
1
Victor NOËL
Thu, 29 Oct 2015 - 09:16:37 +0100
Open Open In Progress In Progress
8h 23m
1
Victor NOËL
Thu, 29 Oct 2015 - 17:40:35 +0100
In Progress In Progress Resolved Resolved
9s
1
Victor NOËL
Thu, 29 Oct 2015 - 17:40:44 +0100



People

Dates

  • Created:
    Thu, 5 Apr 2012 - 14:49:30 +0200
    Updated:
    Wed, 16 Dec 2015 - 16:27:47 +0100
    Resolved:
    Thu, 29 Oct 2015 - 17:40:44 +0100