Bug 901192 (JBPAPP6-1638)

Summary:	CLONE - The command :reload does not check the new configuration, and will cause server crashes if that config is broken
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Tom Fonteyne <tfonteyn>
Component:	Server	Assignee:	Brian Stansberry <brian.stansberry>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	6.0.0	CC:	brian.stansberry, gianluca.pasqualini, jcechace, pgier, pkremens, rsvoboda, tfonteyn
Target Milestone:	ER2
Target Release:	EAP 6.1.0
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/JBPAPP6-1638
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-11-20 13:47:11 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 Tom Fonteyne 2012-11-19 13:31:14 UTC

Help Desk Ticket Reference: https://c.na7.visual.force.com/apex/Case_View?id=500A000000BeaCj&sfdc.override=1
Steps to Reproduce: Have a host controller (can be the DC itself) with one server up and running.

Modify manually the host.xml, introducing a typo, for example remove a "<" from tag.

From the CLI, execute:   /host=master:reload

The result is the host controller AND the server process quitting.


It would seem reasonable that the "reload" at least checks the new xml for schema errors and rejects it.
project_key: JBPAPP6

The command :reload does not check the new configuration, and will cause server crashes if that config is broken

Comment 1 Tom Fonteyne 2012-11-19 13:31:15 UTC

Link: Added: This issue Cloned from AS7-5976

Comment 2 Tom Fonteyne 2012-11-19 13:35:02 UTC

Workflow: Removed: GIT Pull Request workflow  Added: jira
Security: Added: Public

Comment 4 Brian Stansberry 2012-11-19 15:05:07 UTC

First, editing the xml file underneath a running server is a bad practice we shouldn't attempt to support.

Second, it does check the xml – when it parses it. The only reason to do basic validation before shutting down the old services is to support people trying to manually edit the xml under a running server. For which, see above.

Comment 5 Tom Fonteyne 2012-12-10 09:16:25 UTC

reopening as per Brian's request

Comment 6 Rostislav Svoboda 2013-02-21 10:55:11 UTC

Is this item targeted to EAP 6.1.0 ? If yes, please add 'jboss-eap-6.1.0' flag.

Comment 7 Brian Stansberry 2013-02-21 21:02:01 UTC

This will be in EAP 6.1.0. It was fixed in upstream quite a while ago.

Comment 8 Jakub Cechacek 2013-03-29 13:24:07 UTC

Unless I'm doing something wrong the behavior in ER3 is exactly the same as described in bug report. After performing  /host=master:reload with the corrupted host.xml server process will quit with ConfigurationPersistenceException.  

Changing status back to assigned

Comment 9 Brian Stansberry 2013-04-01 15:07:36 UTC

See my comment on Dec 10 on AS7-5976:

"The critical task here is to validate the behavior is correct if the reload operation includes the restart-servers=false parameter. In that case the user's intent is the servers remain unaffected by the reload, so having the PC terminate due to failure is incorrect.

Having the PC terminate due to failure to reload the HC is ok if no servers are running, as a PC with no servers and an unusable HC is of little value."


So, use /host=master:reload(restart-servers=false) to check the behavior if you don't want servers affected.

Comment 10 Petr Kremensky 2013-04-04 10:23:03 UTC

Verified on EAP 6.1.0 ER4. 

Corrupting the host.xml and calling /host=master:reload(restart-servers=false) won't affect running servers. PC without running servers is terminated.

Comment 13 mark yarborough 2013-07-23 18:46:46 UTC

Details inside vpn: https://post-office.corp.redhat.com/mailman/private/eap-pm-list/2013-July/msg00105.html