Details
-
Type:
Improvement Request
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.5.0
-
Fix Version/s: 5.6.0
-
Component/s: Monitoring (Business)
-
Security Level: Public
-
- Environment:
- -
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue blocks |
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Major [ 3 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Summary | Introduce Consume Flow traces and simplify Consume Ext ones | Simplify Consume Ext traces to not include redundant information and be logged earlier |
| Description |
Currently, ConsumeExt flow traces are used both to denote an external event arriving in the bus and the send of an exchange into the bus.
It could make sense to differentiate the two: a trace to log the external event (ConsumeExtFlow) and a trace to log the moment an exchange is sent to bus (ConsumeFlow). An example is if an error occurs before the exchange is sent (e.g., the SOAP BC receive a request which is mapped to nothing, so only ConsumeExt traces are logged). ConsumeFlow could seem to be redundant with ProvideFlow, but there is two reasons for them to exist: * it is needed to know, from the pov of the consumer, which interface/service/endpoint/operation was addressed * it is needed to denote timeout of sendSync (see The CDK should take care of logging the Consume traces and the BCs should log the ConsumeExt as soon as possible! |
Currently, ConsumeExt flow traces are used both to denote an external event arriving in the bus and the send of an exchange into the bus.
It could make sense to differentiate the two: a trace to log the external event (ConsumeExtFlow) and a trace to log the moment an exchange is sent to bus (ConsumeFlow). An example is if an error occurs before the exchange is sent (e.g., the SOAP BC receive a request which is mapped to nothing, so only ConsumeExt traces are logged). ConsumeFlow is actually redundant with ProvideFlow, but there could be those reasons for it to exist: * it enables to know in case of failure if a problem happened before the exchange was sent (before ConsumeFlow is logged) or after. * it enables to compute the processing time of a component (before ConsumeFlow is logged) versus the time for transport (until ProvideFlow is logged). Nevertheless, introducing the ConsumeFlow seems awkward for the following reasons: * the aforementionned justifications are not business but technical * this would mean there is two steps for the processing of a given service (the ConsumeExt then the Consume even though conceptually there is only one step happening) Hence, we won't introduce ConsumeFlow for now but simply simplify the ConsumeExt and log it earlier. |
| Link |
This issue blocks |
| Resolution | Fixed [ 1 ] | |
| Fix Version/s | 5.6.0 [ 10611 ] | |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Transition | Status Change Time | Execution Times | Last Executer | Last Execution Date | |||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
updated description to explain why ConsumeFlow won't be added