Petals ESB Container

Successful creation of... 2 EPs with same name !

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 3.1.1
  • Fix Version/s: 3.1.2, 4.0.0
  • Component/s: Registry
  • Security Level: Public
  • Description:
    Hide

    Recipe follows:

    • Petals "Node 1" in standalone mode, deploy endpoint (Interface,Service,EP)
    • Petals "Node 2" in standalone mode, deploy same endpoint (Interface,Service,EP)
    • Stop nodes
    • Reconfigure topology: Node 1 is master, Node 2 is slave
    • Start Node 1, then Node 2
      Doing so, you will obtain 2 EPs with same name (Interface,Service,EP).
      Don't know which one is invoked... but it works if a client calls the EP.
    Show
    Recipe follows:
    • Petals "Node 1" in standalone mode, deploy endpoint (Interface,Service,EP)
    • Petals "Node 2" in standalone mode, deploy same endpoint (Interface,Service,EP)
    • Stop nodes
    • Reconfigure topology: Node 1 is master, Node 2 is slave
    • Start Node 1, then Node 2 Doing so, you will obtain 2 EPs with same name (Interface,Service,EP). Don't know which one is invoked... but it works if a client calls the EP.
  • Environment:
    Linux

Activity

Ascending order - Click to sort in descending order
Roland Naudin made changes - Tue, 21 Dec 2010 - 11:01:12 +0100
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Critical [ 2 ]
Component/s Registry [ 10058 ]
Component/s Topology/network [ 10061 ]
Hide
Permalink
Roland Naudin added a comment - Tue, 21 Dec 2010 - 11:07:23 +0100

It must be forbidden to deploy the same endpoint (endpointname/serviceName) twice in a Petals domain.

Show
Roland Naudin added a comment - Tue, 21 Dec 2010 - 11:07:23 +0100 It must be forbidden to deploy the same endpoint (endpointname/serviceName) twice in a Petals domain.
Hide
Permalink
Christophe DENEUX added a comment - Tue, 21 Dec 2010 - 11:15:59 +0100

Yes, but because of:

  • the clean of the registry on startup,
  • the delay before the first synchronization,
    on each node, the other endpoint is not kown, so you can deploy you local endpoint.

I think it's a consequence of a defect of the registry

Show
Christophe DENEUX added a comment - Tue, 21 Dec 2010 - 11:15:59 +0100 Yes, but because of:
  • the clean of the registry on startup,
  • the delay before the first synchronization, on each node, the other endpoint is not kown, so you can deploy you local endpoint.
I think it's a consequence of a defect of the registry
Hide
Permalink
Pierre-Yves Gibello added a comment - Tue, 21 Dec 2010 - 11:28:33 +0100

Right, it was not intentional... but the registry accepted the 2 EPs (they were visible in the sample client's EP list).

Show
Pierre-Yves Gibello added a comment - Tue, 21 Dec 2010 - 11:28:33 +0100 Right, it was not intentional... but the registry accepted the 2 EPs (they were visible in the sample client's EP list).
Hide
Permalink
Christophe Hamerling added a comment - Tue, 21 Dec 2010 - 11:44:09 +0100

Not sure that there are such constraint in the DB table...

Show
Christophe Hamerling added a comment - Tue, 21 Dec 2010 - 11:44:09 +0100 Not sure that there are such constraint in the DB table...
Hide
Permalink
Christophe DENEUX added a comment - Fri, 1 Apr 2011 - 11:26:02 +0200

Christophe, are you sure adding a constraint will solve the problem ? On the master, the constraint will avoid:

  • to insert the second EPs (EP of the slave) on the master
  • to insert a second EP (EP of the master) on the slave
    and so, we will not have the same endpoint on each node.
Show
Christophe DENEUX added a comment - Fri, 1 Apr 2011 - 11:26:02 +0200 Christophe, are you sure adding a constraint will solve the problem ? On the master, the constraint will avoid:
  • to insert the second EPs (EP of the slave) on the master
  • to insert a second EP (EP of the master) on the slave and so, we will not have the same endpoint on each node.
Hide
Permalink
Christophe DENEUX added a comment - Wed, 4 May 2011 - 18:14:19 +0200

Even if the registry is synchronized, we can deployed the same endpoint twice.
It seems that a check is missing.

Show
Christophe DENEUX added a comment - Wed, 4 May 2011 - 18:14:19 +0200 Even if the registry is synchronized, we can deployed the same endpoint twice. It seems that a check is missing.
Christophe DENEUX made changes - Wed, 4 May 2011 - 18:14:25 +0200
Assignee Roland Naudin [ rnaudin ] Christophe DENEUX [ cdeneux ]
Christophe DENEUX made changes - Wed, 4 May 2011 - 18:14:27 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Christophe DENEUX added a comment - Mon, 9 May 2011 - 15:42:57 +0200

Now in petals-entreprise-3.1.x, if the registry is synchronized, an error occurs when installing an endpoint twice.

Show
Christophe DENEUX added a comment - Mon, 9 May 2011 - 15:42:57 +0200 Now in petals-entreprise-3.1.x, if the registry is synchronized, an error occurs when installing an endpoint twice.
Christophe DENEUX made changes - Mon, 9 May 2011 - 15:42:57 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 3.1.2 [ 10156 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Christophe DENEUX added a comment - Mon, 9 May 2011 - 15:43:23 +0200

To merge in trunk and to complete against registry synchronization

Show
Christophe DENEUX added a comment - Mon, 9 May 2011 - 15:43:23 +0200 To merge in trunk and to complete against registry synchronization
Christophe DENEUX made changes - Mon, 9 May 2011 - 15:43:23 +0200
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Mathieu Carrolle made changes - Mon, 12 Sep 2011 - 13:56:32 +0200
Assignee Christophe DENEUX [ cdeneux ] Mathieu Carrolle [ mcarrolle ]
Mathieu Carrolle made changes - Mon, 12 Sep 2011 - 13:56:35 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Mathieu Carrolle made changes - Mon, 12 Sep 2011 - 13:56:49 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 4.0.0 [ 10108 ]
Fix Version/s 3.1.2 [ 10156 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Mon, 12 Sep 2011 - 14:26:37 +0200
Fix Version/s 3.1.2 [ 10156 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
9m 34s
1
Roland Naudin
Tue, 21 Dec 2010 - 11:01:12 +0100
Open Open In Progress In Progress
134d 6h 13m
1
Christophe DENEUX
Wed, 4 May 2011 - 18:14:27 +0200
In Progress In Progress Resolved Resolved
4d 21h 28m
1
Christophe DENEUX
Mon, 9 May 2011 - 15:42:57 +0200
Resolved Resolved Open Open
26s
1
Christophe DENEUX
Mon, 9 May 2011 - 15:43:23 +0200
Open Open In Progress In Progress
125d 22h 13m
1
Mathieu Carrolle
Mon, 12 Sep 2011 - 13:56:35 +0200
In Progress In Progress Resolved Resolved
14s
1
Mathieu Carrolle
Mon, 12 Sep 2011 - 13:56:49 +0200



People

Dates

  • Created:
    Tue, 21 Dec 2010 - 10:51:38 +0100
    Updated:
    Mon, 12 Sep 2011 - 14:26:37 +0200
    Resolved:
    Mon, 12 Sep 2011 - 13:56:49 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.