[JBoss JIRA] (WFCORE-2070) Domain server resource should have kill/destroy operations
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2070:
----------------------------------------
Summary: Domain server resource should have kill/destroy operations
Key: WFCORE-2070
URL: https://issues.jboss.org/browse/WFCORE-2070
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
The server-config resource has kill/destroy ops for the server. These should be present on the server resource as well.
This is part of the overall user experience effort of not using server-config for lifecycle ops, since the resource is about the config the HC uses for the server not its runtime.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7711) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7711?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-7711:
---------------------------------
Description: Add the code for the actual opt-in. See details on WFCORE-1677. (was: It sounds to me that the test should really be validating the generated XML files, rather than the templates.
{noformat}
testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
at javax.xml.validation.Validator.validate(Validator.java:124)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
Results :
Failed tests:
SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
{noformat})
> Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7711
> URL: https://issues.jboss.org/browse/WFLY-7711
> Project: WildFly
> Issue Type: Task
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> Add the code for the actual opt-in. See details on WFCORE-1677.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7711) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7711?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved WFCORE-2069 to WFLY-7711:
----------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-7711 (was: WFCORE-2069)
Component/s: (was: Test Suite)
Affects Version/s: (was: 2.2.0.CR8)
Fix Version/s: 10.1.0.Final
(was: 3.0.0.Alpha13)
> Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7711
> URL: https://issues.jboss.org/browse/WFLY-7711
> Project: WildFly
> Issue Type: Task
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> It sounds to me that the test should really be validating the generated XML files, rather than the templates.
> {noformat}
> testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
> java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
> at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
> at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
> at javax.xml.validation.Validator.validate(Validator.java:124)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
> at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
> at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
> Results :
> Failed tests:
> SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2069) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests
by Radoslav Husar (JIRA)
Radoslav Husar created WFCORE-2069:
--------------------------------------
Summary: Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests
Key: WFCORE-2069
URL: https://issues.jboss.org/browse/WFCORE-2069
Project: WildFly Core
Issue Type: Task
Components: Test Suite
Affects Versions: 2.2.0.CR8
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Priority: Minor
Fix For: 3.0.0.Alpha13
It sounds to me that the test should really be validating the generated XML files, rather than the templates.
{noformat}
testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
at javax.xml.validation.Validator.validate(Validator.java:124)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
Results :
Failed tests:
SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2068:
-------------------------------------
Summary: HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue (was: HTTPSConnectionWithCLITestCase Failing Due To Native Protocol Issue)
> HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
> Priority: Blocker
> Fix For: 3.0.0.Alpha14
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2137) JGroups: one slow/stuck node slows/freezes entire cluster
by Bharad S (JIRA)
[ https://issues.jboss.org/browse/JGRP-2137?page=com.atlassian.jira.plugin.... ]
Bharad S commented on JGRP-2137:
--------------------------------
Thanks. Will try it out and let you know.
> JGroups: one slow/stuck node slows/freezes entire cluster
> ---------------------------------------------------------
>
> Key: JGRP-2137
> URL: https://issues.jboss.org/browse/JGRP-2137
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Multi node cluster. Uses TUNNEL mode with GossipRouter, TCP.
> Reporter: Bharad S
> Assignee: Bela Ban
> Attachments: replication-server.xml
>
>
> We have a multi node cluster with one node (say Node A) running the gossip router. We use TUNNEL mode, i.e., other nodes in cluster can talk to each other only via Node A. If one of the nodes in the cluster (say Node B) is slow in reading or gets stuck while reading from the channel, it affects the entire cluster. Inter node gossip also gets stuck and the nodes fall out of cluster.
> Thread dump on Node A indicate that 'ConnectionHandler' for node B stuck (at SocketOutputStream.socketWrite) while it is holding on to a lock, thus blocking ConnectionHandlers for all other nodes.
> --snip (from thread dump on Node A) --
> "gossip-handlers-129" #1088 daemon prio=5 os_prio=0 tid=0x00007f65d20ce800 nid=0x2353 runnable [0x00007f6557efd000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
> at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
> at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:857)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:828)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> - locked <0x00000005f2445028> (a sun.security.ssl.AppOutputStream)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> - locked <0x00000005f248a210> (a java.io.BufferedOutputStream)
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> at org.jgroups.stack.GossipRouter.sendToMember(GossipRouter.java:607)
> - locked <0x00000005f248a1f0> (a java.io.DataOutputStream)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:590)
> - locked <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> --snip end--
> Other gossip-handler threads (meant for other nodes in the cluster) on Node A wait for acquiring lock on the ConnectionHandler map at following place: GossipRouter.java, method: sendToAllMembersInGroup
> --snip--
> "gossip-handlers-128"
> #1078 daemon prio=5 os_prio=0 tid=0x00007f65d20ce000 nid=0x2343 waiting
> for monitor entry [0x00007f654c258000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583)
> - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> "gossip-handlers-127"
> #1073 daemon prio=5 os_prio=0 tid=0x00007f65d01a6800 nid=0x233c waiting
> for monitor entry [0x00007f6697afb000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.stack.GossipRouter.sendToAllMembersInGroup(GossipRouter.java:583)
> - waiting to lock <0x00000005d4aa1458> (a java.util.concurrent.ConcurrentHashMap)
> at org.jgroups.stack.GossipRouter.route(GossipRouter.java:487)
> at org.jgroups.stack.GossipRouter.access$800(GossipRouter.java:63)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.readLoop(GossipRouter.java:753)
> at org.jgroups.stack.GossipRouter$ConnectionHandler.run(GossipRouter.java:706)
> at java.lang.Thread.run(Thread.java:745)
> --snip end--
> If node B were to go down, JGroups quickly takes it out of the cluster and
> there is no problem. But if it stays in the cluster and is slow/stuck, is
> there a way to avoid rest of the cluster getting affected? We'd
> appreciate any help/pointers. Thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months