Bug 900714 (JBPAPP6-1067)

Summary:	SingletonService is not stopped after cluster split/merge
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Wolf-Dieter Fink <wolfdieter.fink>
Component:	Clustering	Assignee:	Paul Ferraro <paul.ferraro>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	6.0.0	CC:	bmaxwell, lthon, paul.ferraro, rhusar, twells, wolfdieter.fink
Target Milestone:	---
Target Release:	EAP 6.0.1
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/JBPAPP6-1067
Whiteboard:	cluster service singleton
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:	Two servers in standalone-ha mode
Last Closed:	2012-10-26 10:24:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Wolf-Dieter Fink 2012-07-19 08:33:13 UTC

Affects: Release Notes
Steps to Reproduce: - Start two nodes with standalone-ha.xml
- Deploy quickstart cluster-ha-singleton-ejb
- The timer is started once and log every ten seconds
- stop the node with the timer (Ctrl-Z in the console)
- wait for shunning and the timer start on the second
- resume the node (command fg)
- After the cluster is merged both timers are active
project_key: JBPAPP6

If a SingletonService is deployed on both nodes it will start on one node only, also it works if nodes are leaving or joining the cluster if it is shutdowned, crashed or started.
But in case of a cluster merge I expect that the method stop() will be called.
But the service is still running on two nodes after merge.

Comment 1 Wolf-Dieter Fink 2012-07-19 08:33:14 UTC

Link: Added: This issue Cloned from AS7-5218

Comment 2 Wolf-Dieter Fink 2012-07-19 08:34:32 UTC

Workflow: Removed: GIT Pull Request workflow  Added: jira
Security: Added: Public
Docs QE Status: Added: NEW

Comment 3 Paul Ferraro 2012-08-08 20:14:45 UTC

Issue is fixed and is awaiting testing against latest EAP DR.

Comment 4 Wolf-Dieter Fink 2012-10-09 14:40:09 UTC

Link: Added: This issue Cloned to JBPAPP-10152

Comment 6 Dana Mison 2012-10-19 04:40:12 UTC

Affects: Added: Release Notes

Comment 7 Dana Mison 2012-10-19 07:04:37 UTC

Release Notes Docs Status: Added: Not Yet Documented
Writer: Added: tomwells

Comment 8 Tom WELLS 2012-10-22 05:40:56 UTC

Hey Guys,

Could someone please provide me with a summary of what caused this issue, what the consequence for the customer was, how it was fixed, and how SingletonService behaves differently now.

Thanks.

Comment 9 Tom WELLS 2012-10-22 05:40:56 UTC

Release Notes Docs Status: Removed: Not Yet Documented Added: Needs More Info

Comment 10 Wolf-Dieter Fink 2012-10-22 06:23:16 UTC

Hey Tom,

a SingletonService is implemented as a service that will only run once in a clustered environment. This has worked as expected if cluster members are started and stopped by 'normal' admin operations.
But if there are network problems (disconnected) and the cluster was splitted there are two clusters and each act as 'one and only' so the result is that two instances of the SingletonService are active, which is correct at this moment.
After the members find together again there are two active instances and one of it must be stopped to respect the singleton approach, but the problem was that two (or more) instances stay active whitout respect to the elected cluster-master node which is unwanted.
With the fix the instance which is running on the not elected node will be deactivated by calling the stop() method of the instance and the result is one active instance on the elected cluster-master node.

Comment 11 Tom WELLS 2012-10-23 06:06:34 UTC

Release Notes Docs Status: Removed: Needs More Info Added: Documented as Resolved Issue
Release Notes Text: Added: One instance of SingletonService is intended to run per cluster. If a cluster is split due to networking issues, one instance of the SingletonService would run in each cluster, which caused problems when the split cluster members rejoined the original cluster. The instance run in the non-elected cluster-master node is now deactivated by calling its stop() method, and there is only one active instance.

Comment 12 Ladislav Thon 2012-10-26 10:24:57 UTC

Verified on EAP 6.0.1 ER3

Comment 13 Anne-Louise Tangring 2012-11-13 20:21:00 UTC

Release Notes Docs Status: Removed: Documented as Resolved Issue 
Writer: Removed: tomwells 
Release Notes Text: Removed: One instance of SingletonService is intended to run per cluster. If a cluster is split due to networking issues, one instance of the SingletonService would run in each cluster, which caused problems when the split cluster members rejoined the original cluster. The instance run in the non-elected cluster-master node is now deactivated by calling its stop() method, and there is only one active instance. 
Docs QE Status: Removed: NEW