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

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

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.