Bug 780229 (SOA-2616)

Summary:	Provide alternative registry implementation
Product:	[JBoss] JBoss Enterprise SOA Platform 5	Reporter:	Martin Weiler <mweiler>
Component:	JBossESB, jUDDI - within SOA	Assignee:	tcunning
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	5.0.2	CC:	daniel.bevenius, darran.lofthouse, kevin.conner, ldimaggi
Target Milestone:	---
Target Release:	FUTURE
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/SOA-2616
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martin Weiler 2010-11-29 14:48:10 UTC

Help Desk Ticket Reference: https://na7.salesforce.com/500A00000045LkR
project_key: SOA

The issue here is: in a cluster environment, after a malfunction on JBoss (e.g.  JVM crash, erroneous deployment etc) the registry remains with invalid endpoints and the ESB has an erroneous behavior by using those endpoints. Even your removeDeadEPR property is unusable, because as stated in the documentation the "the end-point reference for a service that is [...] slow to respond may, inadvertently, be removed from the registry by mistake".

Since we have a cluster and to manually clean the DB is not just to drop the tables and restart the server, this is a major issue for us, because it can lead to erroneous service calls if a server node crashes.

Comment 2 Kevin Conner 2010-11-29 15:04:50 UTC

Changed to a feature request to replace jUDDI as the registry implementation.

Comment 5 Anne-Louise Tangring 2010-12-01 17:52:50 UTC

Investigation needed. See Kevin's comment.

Comment 6 tcunning 2011-07-08 18:40:29 UTC

Link: Added: This issue relates to JBESB-3629

Comment 7 Kurt Stam 2011-08-23 14:31:46 UTC

When using jUDDI v3, it makes much more sense to use user defined keys, and have part of the binding key be the host and port name. This way the existing binding keys are simply reused rather then a new set being created when the servers come back up. Also the new jUDDI v3.1 client ships with a service cache, which is updated by a subscription (when a service or endpoints change or are removed the client caches are informed). This is using standard UDDI v3 functionality so should work with any v3 registry and makes the registry much more dynamic.

This reduces the problem to removing dead endpoint information of nodes that are really gone. I would think that a 3 'strikes you're out' policy in the ServiceInvoker should do the trick, that with an optional periodic query ("am I in the registry") - if not, reregistration to bring back services that could not be seen due to for example temporary network issues.

"The real solution is to have a 'service repository' that reacts dynamically to cluster members appearing/disappearing" if you have this info then you can do registration/unregistration right there..

My 2 cents.

--Kurt

Comment 8 Kevin Conner 2011-08-23 14:43:32 UTC

It is not the client behaviour that is the issue here, rather it is the missing 'dead endpoint information' of the nodes that have disappeared.  The 'three strikes' doesn't work given the number of times this is raised by customers.

Having an alternate implementation which can react to the topology changes is preferable.

Kev

Comment 9 Kevin Conner 2011-08-23 14:45:02 UTC

Sorry, I should clarify and say that the 'three strikes' wouldn't work given that customers are unhappy with the current implementation (possible removal after one).