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
-
- Environment:
- -
Issue Links
| Depends | |||
|---|---|---|---|
|
|||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Mathieu Carrolle [ mcarrolle ] | |
| Priority | Major [ 3 ] |
| Fix Version/s | 5.4.0 [ 10362 ] |
| Fix Version/s | VNext [ 10406 ] | |
| Fix Version/s | 5.4.0 [ 10362 ] |
| 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. |
| 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. |
| 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. |
| Link |
This issue depends on |
| Fix Version/s | 5.5.1 [ 10599 ] | |
| Fix Version/s | 5.5.0 [ 10406 ] |
| Fix Version/s | 5.6.0 [ 10611 ] | |
| Fix Version/s | 5.5.1 [ 10599 ] |
| Link |
This issue depends on |
| Status | New [ 10000 ] | Open [ 10002 ] |
| Assignee | Victor NOËL [ vnoel ] |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Link |
This issue depends on |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |