Petals CDK

MONIT traces are not correctly managed when expiration of asynchronous messages

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.2.0, 5.3.0
  • Fix Version/s: 5.6.0
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):

    1. provider side: provideFlowStepBegin,
    2. sub-provider #1 side (another provider invoked asynchronously): provideFlowStepBegin,
    3. sub-provider #2 side (another provider invoked asynchronously): provideFlowStepBegin,
    4. sub-provider #1 side: provideFlowStepEnd
    5. provider side (the expiration occurs): provideFlowStepEnd. We won't return an error if a time-out occurs
    6. sub-provider #2 side (when the processing ends normally): provideFlowStepEnd.

    Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

    The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.

    Show
    If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
    1. provider side: provideFlowStepBegin,
    2. sub-provider #1 side (another provider invoked asynchronously): provideFlowStepBegin,
    3. sub-provider #2 side (another provider invoked asynchronously): provideFlowStepBegin,
    4. sub-provider #1 side: provideFlowStepEnd
    5. provider side (the expiration occurs): provideFlowStepEnd. We won't return an error if a time-out occurs
    6. sub-provider #2 side (when the processing ends normally): provideFlowStepEnd.
    Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned. The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
  • Environment:
    -

Issue Links

Depends
 

Activity

Ascending order - Click to sort in descending order
Christophe DENEUX made changes - Mon, 4 Jun 2012 - 17:03:07 +0200
Field Original Value New Value
Assignee Mathieu Carrolle [ mcarrolle ]
Priority Major [ 3 ]
Christophe DENEUX made changes - Mon, 4 Jun 2012 - 17:03:26 +0200
Fix Version/s 5.4.0 [ 10362 ]
Christophe DENEUX made changes - Tue, 24 Sep 2013 - 09:27:28 +0200
Fix Version/s VNext [ 10406 ]
Fix Version/s 5.4.0 [ 10362 ]
Hide
Permalink
Victor NOËL added a comment - Mon, 7 Sep 2015 - 10:18:44 +0200

Christophe, any idea about what to do then in this case?

Show
Victor NOËL added a comment - Mon, 7 Sep 2015 - 10:18:44 +0200 Christophe, any idea about what to do then in this case?
Hide
Permalink
Christophe DENEUX added a comment - Mon, 7 Sep 2015 - 11:50:22 +0200

IMO, we should introduced consumeFlowStepBegin, consumeFlowStepEnd and consumeFlowStepFailure in service providers that invoked other service providers, that is not the case today. It's a little redundant with providerFlowStep... of the invoked service providers but we should be able to resolve the current problem with that. The time-out will appear as consumerFlowStepFailure.

Show
Christophe DENEUX added a comment - Mon, 7 Sep 2015 - 11:50:22 +0200 IMO, we should introduced consumeFlowStepBegin, consumeFlowStepEnd and consumeFlowStepFailure in service providers that invoked other service providers, that is not the case today. It's a little redundant with providerFlowStep... of the invoked service providers but we should be able to resolve the current problem with that. The time-out will appear as consumerFlowStepFailure.
Christophe DENEUX made changes - Mon, 7 Sep 2015 - 11:51:28 +0200
Description If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
# provider side: provideFlowStepBegin,
# sub-provider #1 side (another provider invoked asynchronously): provideFlowStepBegin,
# sub-provider #2 side (another provider invoked asynchronously): provideFlowStepBegin,
# sub-provider #1 side: provideFlowStepEnd
# provider side (the expiration occurs): provideFlowStepEnd
# sub-provider #2 side (when the processing ends normally): provideFlowStepEnd.

Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
# provider side: {{provideFlowStepBegin}},
# sub-provider #1 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #2 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #1 side: {{provideFlowStepEnd}}
# provider side (the expiration occurs): {{provideFlowStepEnd}}. We won't return an error if a time-out occur
# sub-provider #2 side (when the processing ends normally): {{provideFlowStepEnd}}.

Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
Christophe DENEUX made changes - Mon, 7 Sep 2015 - 11:51:37 +0200
Description If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
# provider side: {{provideFlowStepBegin}},
# sub-provider #1 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #2 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #1 side: {{provideFlowStepEnd}}
# provider side (the expiration occurs): {{provideFlowStepEnd}}. We won't return an error if a time-out occur
# sub-provider #2 side (when the processing ends normally): {{provideFlowStepEnd}}.

Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
# provider side: {{provideFlowStepBegin}},
# sub-provider #1 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #2 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #1 side: {{provideFlowStepEnd}}
# provider side (the expiration occurs): {{provideFlowStepEnd}}. We won't return an error if a time-out occurs
# sub-provider #2 side (when the processing ends normally): {{provideFlowStepEnd}}.

Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
Christophe DENEUX made changes - Mon, 7 Sep 2015 - 11:51:53 +0200
Description If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
# provider side: {{provideFlowStepBegin}},
# sub-provider #1 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #2 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #1 side: {{provideFlowStepEnd}}
# provider side (the expiration occurs): {{provideFlowStepEnd}}. We won't return an error if a time-out occurs
# sub-provider #2 side (when the processing ends normally): {{provideFlowStepEnd}}.

Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
If a service provider is invoked asynchronously (unblocking call), we get following MONIT traces (for a MEP InOut):
# provider side: {{provideFlowStepBegin}},
# sub-provider #1 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #2 side (another provider invoked asynchronously): {{provideFlowStepBegin}},
# sub-provider #1 side: {{provideFlowStepEnd}}
# provider side (the expiration occurs): {{provideFlowStepEnd}}. We won't return an error if a time-out occurs
# sub-provider #2 side (when the processing ends normally): {{provideFlowStepEnd}}.


Point #5: it's normal to have a 'provideFlowStepEnd' because it's based on the reply returns to the consumer of the main provider. In case of an orchestration, if a timout occurs, a response that is not an error or a fault can be returned.

The expiration does not appear anywhere. And its very difficult to understand point 5 and 6 in temporal point of view.
Hide
Permalink
Victor NOËL added a comment - Tue, 8 Sep 2015 - 16:25:28 +0200

I'm wondering if it makes sense to log a MONIT end or MONIT failure when an answer is sent (at the provider side, as we do currently) instead of logging it when the consumer receives it.

If it was done as in the second case, then we could handles this issue by logging a failure when we realise the exchange was sent with sendAsync and it had expired.

Just an idea… more generally, it would make sense to log the MONIT trace only when the consumer received the answer properly, because if there is, for example, a problem during remote transport, the logs kind of lie about the fact the exchange is finished...

We could even go farther and say that we should only log the MONIT end when the provider receives the DONE after the consumer got its response…

Show
Victor NOËL added a comment - Tue, 8 Sep 2015 - 16:25:28 +0200 I'm wondering if it makes sense to log a MONIT end or MONIT failure when an answer is sent (at the provider side, as we do currently) instead of logging it when the consumer receives it. If it was done as in the second case, then we could handles this issue by logging a failure when we realise the exchange was sent with sendAsync and it had expired. Just an idea… more generally, it would make sense to log the MONIT trace only when the consumer received the answer properly, because if there is, for example, a problem during remote transport, the logs kind of lie about the fact the exchange is finished... We could even go farther and say that we should only log the MONIT end when the provider receives the DONE after the consumer got its response…
Christophe DENEUX made changes - Fri, 11 Sep 2015 - 14:17:50 +0200
Link This issue depends on PETALSDISTRIB-152 [ PETALSDISTRIB-152 ]
Hide
Permalink
Victor NOËL added a comment - Mon, 14 Sep 2015 - 13:15:35 +0200

ConsumeFlowStepXXX was renamed to ConsumeExtFlowStepXXX.

If we ever introduce a ConsumeFlowStepXXX (for the actual send inside the ESB), we should be extra careful that they appear in the correct order

Show
Victor NOËL added a comment - Mon, 14 Sep 2015 - 13:15:35 +0200 ConsumeFlowStepXXX was renamed to ConsumeExtFlowStepXXX. If we ever introduce a ConsumeFlowStepXXX (for the actual send inside the ESB), we should be extra careful that they appear in the correct order
Christophe DENEUX made changes - Mon, 5 Oct 2015 - 10:58:42 +0200
Fix Version/s 5.5.1 [ 10599 ]
Fix Version/s 5.5.0 [ 10406 ]
Victor NOËL made changes - Wed, 16 Dec 2015 - 16:27:45 +0100
Fix Version/s 5.6.0 [ 10611 ]
Fix Version/s 5.5.1 [ 10599 ]
Victor NOËL made changes - Wed, 30 Mar 2016 - 13:46:01 +0200
Link This issue depends on PETALSCDK-171 [ PETALSCDK-171 ]
Victor NOËL made changes - Wed, 30 Mar 2016 - 13:46:19 +0200
Status New [ 10000 ] Open [ 10002 ]
Assignee Victor NOËL [ vnoel ]
Victor NOËL made changes - Wed, 30 Mar 2016 - 13:46:22 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Thu, 31 Mar 2016 - 15:23:47 +0200
Link This issue depends on PETALSCDK-171 [ PETALSCDK-171 ]
Hide
Permalink
Victor NOËL added a comment - Thu, 31 Mar 2016 - 15:26:32 +0200

In the end, the best solution to resolve the problem of the description is:

  • when possible, the provideFlowStepFailure should be logged if one of the sub-provider failed
  • if not possible (in specific case where it does not make sense), then an error should be logged

It would make sense that usually, a provideFlowStepFailure should most certainly be logged, I don't see how a failure to contact one of the sub-provider would result in the success of a composition…

Show
Victor NOËL added a comment - Thu, 31 Mar 2016 - 15:26:32 +0200 In the end, the best solution to resolve the problem of the description is:
  • when possible, the provideFlowStepFailure should be logged if one of the sub-provider failed
  • if not possible (in specific case where it does not make sense), then an error should be logged
It would make sense that usually, a provideFlowStepFailure should most certainly be logged, I don't see how a failure to contact one of the sub-provider would result in the success of a composition…
Victor NOËL made changes - Fri, 1 Apr 2016 - 15:17:13 +0200
Resolution Fixed [ 1 ]
Status In Progress [ 10003 ] Resolved [ 10004 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
1394d 20h 43m
1
Victor NOËL
Wed, 30 Mar 2016 - 13:46:19 +0200
Open Open In Progress In Progress
3s
1
Victor NOËL
Wed, 30 Mar 2016 - 13:46:22 +0200
In Progress In Progress Resolved Resolved
2d 1h 30m
1
Victor NOËL
Fri, 1 Apr 2016 - 15:17:13 +0200

People

Dates

  • Created:
    Mon, 4 Jun 2012 - 17:02:32 +0200
    Updated:
    Fri, 1 Apr 2016 - 15:17:13 +0200
    Resolved:
    Fri, 1 Apr 2016 - 15:17:13 +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.