Petals BC Gateway

Can't use gateway between containers with different SharedArea/ServiceEndpoint implementations

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.0.5
  • Fix Version/s: 1.0.0
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    Context: when connecting a container in, for example, a standalone domain (using the implementation from PETALSESBCONT-433) to a container in a dynamic domain (using the registry overlay implementation).

    Problem: the two shared area implementations use different endpoint implementations and thus when the exchange is deserialized on the standalone domain container, it can't find the exchange's endpoint class.

    Show
    Context: when connecting a container in, for example, a standalone domain (using the implementation from PETALSESBCONT-433) to a container in a dynamic domain (using the registry overlay implementation). Problem: the two shared area implementations use different endpoint implementations and thus when the exchange is deserialized on the standalone domain container, it can't find the exchange's endpoint class.
  • Environment:
    -

Activity

Victor NOËL made changes - Tue, 28 Jun 2016 - 16:57:24 +0200
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Hide
Victor NOËL added a comment - Thu, 30 Jun 2016 - 14:40:57 +0200

Two points:

  1. There is no reason to actually send the endpoints over to the other domain, so we could fix that at the gateway level.
  2. But more generally, it would make sense to ensure that exchanges are not tied to a given configuration of the container as possible (for example for when we have persistence to disk and maybe we restart the container with another configuration, or data is copied to another node, or something like that…)
Show
Victor NOËL added a comment - Thu, 30 Jun 2016 - 14:40:57 +0200 Two points:
  1. There is no reason to actually send the endpoints over to the other domain, so we could fix that at the gateway level.
  2. But more generally, it would make sense to ensure that exchanges are not tied to a given configuration of the container as possible (for example for when we have persistence to disk and maybe we restart the container with another configuration, or data is copied to another node, or something like that…)
Victor NOËL made changes - Tue, 6 Sep 2016 - 16:47:18 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Wed, 7 Sep 2016 - 16:28:02 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 1.0.0 [ 10645 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
11s
1
Victor NOËL
Tue, 28 Jun 2016 - 16:57:24 +0200
Open Open In Progress In Progress
69d 23h 49m
1
Victor NOËL
Tue, 6 Sep 2016 - 16:47:18 +0200
In Progress In Progress Resolved Resolved
23h 40m
1
Victor NOËL
Wed, 7 Sep 2016 - 16:28:02 +0200



People

Dates

  • Created:
    Tue, 28 Jun 2016 - 16:57:13 +0200
    Updated:
    Wed, 7 Sep 2016 - 16:28:02 +0200
    Resolved:
    Wed, 7 Sep 2016 - 16:28:01 +0200