[#PETALSCDK-101] MONIT traces are not correctly managed when expiration of asynchronous messages - Petals Link JIRA

Details

Type: Bug
Status: Resolved
Priority: 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):

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.
Show
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.

Environment:

-

Issue Links

Depends

This issue depends on:
~~PETALSDISTRIB-152~~ MONIT Traces: rename ConsumeFlowStepXXX to ConsumeExtFlowStepXXX

Activity

Ascending order - Click to sort in descending order

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.

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

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 - 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…

Petals CDK

MONIT traces are not correctly managed when expiration of asynchronous messages

Details

Issue Links

Activity

People

Dates