Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 5.0.0
-
Fix Version/s: None
-
Component/s: ComponentContext
-
Security Level: Public
-
- Environment:
- -
Issue Links
| Depends | |||
|---|---|---|---|
|
|||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Major [ 3 ] |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Description |
Currently, the resolveEndpointReference method of the component context tries to resolve endpoints only by relying on the components installed on the local node.
It should resolve them using the whole topology, maybe using the EndpointDirectory, but this is not trivial because resolving endpoint is something that can only be done dynamically by a component, you can't really store the resolved endpoint in a shared space and resolve it there... The idea of resolving endpoint reference is maybe not the best w.r.t. distribution... |
Currently, the resolveEndpointReference method of the component context tries to resolve endpoints only by relying on the components installed on the local node.
It should resolve them using the whole topology, maybe using the EndpointDirectory, but this is not trivial because resolving endpoint is something that can only be done dynamically by a component, you can't really store the resolved endpoint in a shared space and resolve it there... The idea of resolving endpoint reference is maybe not the best w.r.t. distribution... Maybe in the future we should rely on the distributed computing capabilities of the SharedArea implementation (hazelcast) to solve this problem... |
| Link |
This issue depends on |
| Transition | Status Change Time | Execution Times | Last Executer | Last Execution Date | |||||||||
|
|
|
|
|
