Bug 1107869 - Web Console errors out and ends the jbossas process completely [NEEDINFO]
Web Console errors out and ends the jbossas process completely
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Console (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: DR0
: EAP 6.4.0
Assigned To: Harald Pehl
Ondrej Chaloupka
: 995439 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2014-06-10 16:43 EDT by Ahmed Abu Lawi
Modified: 2018-03-06 15:37 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When JTS is enabled in the `Transactions` section of the web management console, it is necessary to also set the attribute `transactions` to the value `on` in the JacORB subsystem. In previous JBoss EAP 6 versions user was not notified about this dependency by management console. The behavior has been corrected in this release by adding a validation check to the console.
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ochaloup: needinfo? (smaestri)

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker HAL-435 Major Resolved Web Console errors out and ends the jbossas process completely 2018-06-22 04:16 EDT

  None (edit)
Description Ahmed Abu Lawi 2014-06-10 16:43:49 EDT
Description of problem:

While conducting smoke tests, changing settings in the web console and reloading the server caused several errors.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

First Bug

1. Start application server.
2. Go to configuration - transactions - common
3. Set the 4 check boxes to true and reload the server.

Second Bug

1. A different error appears if you go to configuration -transactions - Process ID
2. Switch the Process ID UUID checkbox
3. Reload the server

Actual results:

First Bug

./standalone/console.log:72:14:05:41,997 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.Beta2 (AS 7.4.0.Final-redhat-15) started (with errors) in 782ms - Started 128 of 188 services (22 services failed or missing dependencies, 56 services are lazy, passive or on-demand)
./standalone/server.log:362:14:05:41,997 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.Beta2 (AS 7.4.0.Final-redhat-15) started (with errors) in 782ms - Started 128 of 188 services (22 services failed or missing dependencies, 56 services are lazy, passive or on-demand)

Second Bug

16:37:10,388 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.as.server.ServerService.boot(ServerService.java:321) [jboss-as-server-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:254) [jboss-as-controller-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[287,21]
Message: JBAS014724: Missing required attribute(s): socket-binding
	at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:135) [jboss-as-controller-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseSocketProcessIdElement(TransactionSubsystem14Parser.java:415)
	at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseProcessIdEnvironmentElement(TransactionSubsystem14Parser.java:381)
	at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseCoreEnvironmentElement(TransactionSubsystem14Parser.java:340)
	at org.jboss.as.txn.subsystem.TransactionSubsystem15Parser.readElement(TransactionSubsystem15Parser.java:59)
	at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:110)
	at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:53)
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
	at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1035) [jboss-as-server-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:469) [jboss-as-server-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [jboss-as-server-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [jboss-as-server-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.4.0.Final-redhat-15.jar:7.4.0.Final-redhat-15]
	... 3 more

16:37:10,391 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.

Expected results:

Additional info:
These tests were reproduced in RHEL 5 and Fedora.
Comment 2 Brian Stansberry 2014-06-11 11:01:11 EDT
Even if there is a problem with the whatever settings the console is sending over, the transaction subsystem should be detecting that and the request should fail. For sure the second failure type should never occur, where a config is written that can't be parsed.

I believe this should be moved to the Transactions component.
Comment 3 Harald Pehl 2014-06-23 08:14:06 EDT
Sorry for the late response Jakub, but I totally forgot about this one. 

It seems strange that the console should end the JBoss AS process. Moving this to the Transactions component.
Comment 4 Ondrej Chaloupka 2014-06-23 11:31:53 EDT

these are bugs but not on the side of the Transaction Manager but on the side of web console (or maybe management model).

The first bug is caused by setting JTS transactions to be used without setting jacorb subsystem appropriately. This is already filled as the bug here:

The second error is caused by the fact that when you unset the process id then socket is used for UID generation. For that case you have to define name of some socket-binding that will be used for that purpose. When you deselect (set to false) the "process id uuid" item you have to change "process id socket" at the same time. This should be checked by web console (I think).

The both "issues" are documented under "Need Help?" link.

I'm returning this back to Web Console component as Transaction subsystem seems to me to be working fine. Plus it bz#995439 belongs to Web Console component as well.
Comment 5 Brian Stansberry 2014-06-23 13:18:21 EDT
It should also be checked by the subsystem.

If a subsystem is persisting a configuration that cannot boot instead of failing the operation the set up that configuration, the subsystem is broken.

Client side validation is a second line of defense, and very nice for usability.
Comment 6 Jakub Cechacek 2014-06-24 03:01:29 EDT
Ondrej: We can play ping-pong with this if you want. As discussed earlier in regard to BZ995439, I agree that missing validation in console is unpleasant and has an impact on usability -- client side validation has been problematic for a while. However sever missconfiguration should be prevented by subsystem itself. 

Thus as stated by Brian -- There is a usability issue in Admin Console but more sever one in the subsystem itself -- missing config validation.
Comment 7 Heiko Braun 2014-06-24 03:24:03 EDT
Complex interdependencies of attribute values (or lack of) cannot easily be identified and dealt with in the console. 

The bare minimum responsibility for subsystems is to verify the validity of the various combinations prevent illegal state changes. In addition to that subsystems need provide reasonable error messages in case an invalid combination is detected.

Ondrej, please delegate this issue to whatever engineer is responsible for subsystem(s) in question.
Comment 8 tom.jenkinson 2014-06-24 03:49:30 EDT
Hi guys,

As Ondra says, issue 1 is a duplicate so maybe we should remove traces of discussion of issue 1 in this report and Ahmed may I request you enroll yourself as a watcher on https://bugzilla.redhat.com/show_bug.cgi?id=995439.

In terms of issue 2 I again would agree with Ondra. It appears as though the server is partially configured after doing the steps above. I haven't verified the Need Help? link but as Ondra says, if it is described there and the docs that the user has partially configured the system then I don't think it can be considered a transaction manager bug.

I agree it shouldn't be the responsibility of the web console, I would say its more user error if the UI is correctly informing people what to do in the Need Help section.

To Heiko's point "The bare minimum responsibility for subsystems is to verify the validity of the various combinations prevent illegal state changes." I am not a subsystem guru but if the subsystem needs two or more pieces of configuration to become valid, can these be added atomically and if so does the UI support that? To put it in more concrete terms, to correctly configure the setting that the user is trying to do one must:
1. change an enum
2. add a value to indicate a socket binding
3. add the socket binding if it doesn't exist

Is that possible to do atomically? If you can't then as we have discussed above the user has only partially configured the system and that is the reason the server fails to start.

To put in more abstract terms the user has said, "don't configure it this way, use such and such a binding" but then has not provided the binding so when we reboot the TM prevents startup due to the misconfiguration - what do we want to happen in that circumstance?

Comment 9 Brian Stansberry 2014-06-24 09:29:18 EDT

Yes, updates can be performed atomically, so the server should validate that it ends up in a consistent state. I believe Stefano has some experience in how to do this sort of thing, and he should feel free to ping Tomaz Cerar or myself.

The management API includes a "composite" operation whose parameters are a set of operations to execute atomically. The "batch" functionality in the CLI makes use of this.

I don't know if there are any issue in the console with grouping the necessary set of changes in a composite op. I know the console uses composites for some calls, but it's not under explicit user control. So I don't know what the console would do with these attributes.
Comment 10 Ondrej Chaloupka 2014-06-30 09:48:06 EDT
I just found out that the issue from point #2 is already filled as well.
but I do not know how it's wit the PR.
Comment 11 JBoss JIRA Server 2014-07-01 04:39:32 EDT
Harald Pehl <hpehl@redhat.com> updated the status of jira HAL-435 to Coding In Progress
Comment 12 JBoss JIRA Server 2014-07-03 08:06:26 EDT
Harald Pehl <hpehl@redhat.com> updated the status of jira HAL-435 to Resolved
Comment 13 Harald Pehl 2014-07-03 08:07:57 EDT
*** Bug 995439 has been marked as a duplicate of this bug. ***
Comment 14 Ahmed Abu Lawi 2014-07-16 14:12:24 EDT

I was smoke testing the application server recently on RHEL 5, and noticed that bug #1 that I reported above still exists.

To reproduce it:

1) Go to  Configurtation - Container - Transactions
2) Set Enable JTS to True
3) reload the server


./standalone/console.log:72:11:39:19,257 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 812ms - Started 128 of 188 services (22 services failed or missing dependencies, 56 services are lazy, passive or on-demand)
Comment 15 Fernando Nasser 2014-07-16 14:15:46 EDT
Moving to 6.3.1 (tentatively) as this did not get the 3-acks for 6.3.0 and the PR was not merged (still on POST).
Comment 17 tom.jenkinson 2014-12-05 08:26:20 EST
Looks like an upstream Jira was fixed but this was assigned to me for some reason
Comment 19 Jakub Cechacek 2014-12-09 10:46:14 EST
I believe that all the issues mentioned above are now resolved by added validation in console. 

1) it is not possible to enable JTS without Transactions Interceptors ON in JacORB
2) it is not possibel to unset Process ID UUID without specifying a value for Id Socket. 

Verified 6.4.0.DR12

Note You need to log in before you can comment on or make changes to this bug.