Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.5.0
-
Fix Version/s: 5.6.0
-
Component/s: None
-
Security Level: Public
-
- Environment:
- -
Issue Links
| Depends | |||
|---|---|---|---|
|
|
|
||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue blocks |
| 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 ] |
| Link |
This issue blocks |
| Description |
According to the JBI specification (see 7.2.1.2 Endpoint Activation and Deactivation), the contract of the activateEndpoint operation is that an endpoint should be activated ONLY if the component is ready to answer requests.
For SUs, currently, the endpoint is activated on deploy and not after start, which is the moment Petals components usually are ready to answer requests for SUs. For native endpoints, they are activated during init and not after start, which is the moment components are ready to answer native requests. We should thus change the moment we activate the endpoints: at the end of the start of their SU. Conversely, we should deactivate the endpoints before the component stops their SU. We should change the moment we activate the native endpoints: at the end of the component start. Conversely, we should deactivate the native endpoints before the component is stopped. This means also that we should fixes the components that relied on the assumption that their endpoints were activated before start and after stop. |
According to the JBI specification (see 7.2.1.2 Endpoint Activation and Deactivation), the contract of the activateEndpoint operation is that an endpoint should be activated ONLY if the component is ready to answer requests.
For SUs, currently, the endpoint is activated on deploy and not after start, which is the moment Petals components usually are ready to answer requests for SUs. For native endpoints, they are activated during init and not after start, which is the moment components are ready to answer native requests. We should thus change the moment we activate the endpoints: at the end of the start of their SU. Conversely, we should deactivate the endpoints before the component stops their SU. We should NOT change the moment we activate the native endpoints, because this is correct (activated when the component is not shutdown). This means also that we should fixes the components that relied on the assumption that their endpoints were activated before start and after stop. The integration lifecycle test should be updated, and the hack handling exchange for non-started SUs in the Container Router can be safely removed. |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 5.5.1 [ 10599 ] | |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 5.6.0 [ 10611 ] | |
| Fix Version/s | 5.5.1 [ 10599 ] |
| Description |
According to the JBI specification (see 7.2.1.2 Endpoint Activation and Deactivation), the contract of the activateEndpoint operation is that an endpoint should be activated ONLY if the component is ready to answer requests.
For SUs, currently, the endpoint is activated on deploy and not after start, which is the moment Petals components usually are ready to answer requests for SUs. For native endpoints, they are activated during init and not after start, which is the moment components are ready to answer native requests. We should thus change the moment we activate the endpoints: at the end of the start of their SU. Conversely, we should deactivate the endpoints before the component stops their SU. We should NOT change the moment we activate the native endpoints, because this is correct (activated when the component is not shutdown). This means also that we should fixes the components that relied on the assumption that their endpoints were activated before start and after stop. The integration lifecycle test should be updated, and the hack handling exchange for non-started SUs in the Container Router can be safely removed. |
According to the JBI specification (see 7.2.1.2 Endpoint Activation and Deactivation), the contract of the activateEndpoint operation is that an endpoint should be activated ONLY if the component is ready to answer requests.
For SUs, currently, the endpoint is activated on deploy and not after init, which is the moment Petals components should be ready to answer requests for SUs. For native endpoints, they are activated during init, which is the moment components should be ready to answer native requests. We should thus change the moment we activate the endpoints: at the end of the init of their SU. Conversely, we should deactivate the endpoints before the component shutdown their SU. We should NOT change the moment we activate the native endpoints, because this is correct (activated when the component is not shutdown). This means also that we should fix the components that relied on the assumption that their endpoints (SU and native) were activated before init and after shutdown. And we should fix the components that are not ready to serve the messages (for SU and native endpoints) after init and before shutdown. The integration lifecycle test should be updated, and the hack handling exchange for non-started SUs in the Container Router can be safely removed. |