Details
Bug
Resolved
Critical
-
- Environment:
- -
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Critical [ 2 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 5.0.1 [ 10579 ] | |
| Resolution | Fixed [ 1 ] |
| Description |
When there is two sendSync from the same component concerning the same exchange (one acting as a provider and the other as a consumer, most certainly in two different SUs), then a mismatch will happen in the DeliveryChannel implementation between them and provokes incoherent situations.
We should properly differentiate them in the code to avoid that. |
When there is two sendSync from the same component concerning the same exchange (one acting as a provider and the other as a consumer, most certainly in two different SUs), then a mismatch will happen in the DeliveryChannel implementation between them and provokes incoherent situations.
We should properly differentiate them in the code to avoid that. See also |
| Transition | Status Change Time | Execution Times | Last Executer | Last Execution Date | |||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
This does not concerns Petals 4.3 because sendSync takes into account back-and-forth for the same exchange differently than implementation in trunk in local mode (and with NIO there is no problem).