[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)
8 years, 10 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)
8 years, 10 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)
8 years, 10 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)
8 years, 10 months
[JBoss JIRA] (WFLY-7710) Console does not provide an option to kill a server if normal shutdown is hung
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7710?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7710:
----------------------------------------
Oops, I spoke too soon re: current console being better than EAP 6. It seems the current console returns UI control to the user while the "stop" is proceeding in the background. During this period, the UI presents the normal actions as if the server was started. But once the "stop" operation aborts on the server side, the console shows the action list as if the server was stopped.
I think this is a separate issue and may require some server side change to better report to the console the real state of the server. But I think it's probably best to always include the "Force Shutdown" option. Force Shutdown is primarily for pathological situations and that means it's possible the HC is not clear on what the state of the server is. So just always provide it as a choice.
> Console does not provide an option to kill a server if normal shutdown is hung
> ------------------------------------------------------------------------------
>
> Key: WFLY-7710
> URL: https://issues.jboss.org/browse/WFLY-7710
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Reporter: Brian Stansberry
> Assignee: Harald Pehl
>
> I'm experimenting with how an WildFly/EAP domain reacts to failure conditions and noticed that the current console, if a server will not stop, will not provide an option to kill the server.
> My experiment involves a pathological app with a servlet that will never return from it's deplpy() method, meaning the MSC service behind the servlet will never stop, meaning a normal shutdown will never complete.
> The EAP 6 console had "Stop" and "Force Shutdown" links for the servers in the domain topology view. Current console has no "Force Shutdown".
> EAP 6 console has it's own issues in this area, specifically that if the server won't stop, the console reports it stopped anyway, and no longer provides the option to stop or force shutdown. The current console is better in this regard; when the server doesn't shut down the action selections for the server are still the same as if the server was started. So it's just the kill/destroy that is missing.
> See also related JIRA https://issues.jboss.org/browse/WFCORE-2065 for how kill/destroy are suboptimal on the server side. That's mostly an FYI in case during experiments with this you find things are not behaving as you expect.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7710) Console does not provide an option to kill a server if normal shutdown is hung
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-7710:
--------------------------------------
Summary: Console does not provide an option to kill a server if normal shutdown is hung
Key: WFLY-7710
URL: https://issues.jboss.org/browse/WFLY-7710
Project: WildFly
Issue Type: Bug
Components: Web Console
Reporter: Brian Stansberry
Assignee: Harald Pehl
I'm experimenting with how an WildFly/EAP domain reacts to failure conditions and noticed that the current console, if a server will not stop, will not provide an option to kill the server.
My experiment involves a pathological app with a servlet that will never return from it's deplpy() method, meaning the MSC service behind the servlet will never stop, meaning a normal shutdown will never complete.
The EAP 6 console had "Stop" and "Force Shutdown" links for the servers in the domain topology view. Current console has no "Force Shutdown".
EAP 6 console has it's own issues in this area, specifically that if the server won't stop, the console reports it stopped anyway, and no longer provides the option to stop or force shutdown. The current console is better in this regard; when the server doesn't shut down the action selections for the server are still the same as if the server was started. So it's just the kill/destroy that is missing.
See also related JIRA https://issues.jboss.org/browse/WFCORE-2065 for how kill/destroy are suboptimal on the server side. That's mostly an FYI in case during experiments with this you find things are not behaving as you expect.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase 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:
-------------------------------------
Description:
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.
was:
The listed test case is failing during clean up with the following error: -
{noformat}
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 41.112 sec <<< FAILURE! - in org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase
org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase Time elapsed: 7.089 sec <<< ERROR!
org.jboss.as.cli.CommandLineException: The controller is not available at 127.0.0.1:9999
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:180)
at org.jboss.as.cli.impl.CLIModelControllerClient$3.getChannel(CLIModelControllerClient.java:132)
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:75)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1299)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1143)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1120)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.reloadServer(HTTPSConnectionWithCLITestCase.java:175)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.resetTestConfiguration(HTTPSConnectionWithCLITestCase.java:162)
{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.
> HTTPSConnectionWithCLITestCase 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)
8 years, 10 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase Failing Due To Native Protocol Issue
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-2068:
----------------------------------------
Summary: HTTPSConnectionWithCLITestCase 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}
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 41.112 sec <<< FAILURE! - in org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase
org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase Time elapsed: 7.089 sec <<< ERROR!
org.jboss.as.cli.CommandLineException: The controller is not available at 127.0.0.1:9999
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:180)
at org.jboss.as.cli.impl.CLIModelControllerClient$3.getChannel(CLIModelControllerClient.java:132)
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:75)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1299)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1143)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1120)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.reloadServer(HTTPSConnectionWithCLITestCase.java:175)
at org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.resetTestConfiguration(HTTPSConnectionWithCLITestCase.java:162)
{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)
8 years, 10 months
[JBoss JIRA] (ELY-799) Elytron ExternalSaslServerFactory returns EXTERNAL mechanism name when Sasl.POLICY_PASS_CREDENTIALS provided
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-799?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek commented on ELY-799:
---------------------------------
The same is valid for the {{ExternalSaslClientFactory}}. Fix it in both implementations, please.
> Elytron ExternalSaslServerFactory returns EXTERNAL mechanism name when Sasl.POLICY_PASS_CREDENTIALS provided
> ------------------------------------------------------------------------------------------------------------
>
> Key: ELY-799
> URL: https://issues.jboss.org/browse/ELY-799
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> The method {{org.wildfly.security.sasl.external.ExternalSaslServerFactory.getMechanismNames(Map<String, ?>)}} returns the {{"EXTERNAL"}} name also in cases where {{Sasl.POLICY_PASS_CREDENTIALS}} property is provided with {{"true"}} value.
> Only mechanisms which actually pass credentials should be returned for such policy (unless the special {{WildFlySasl#MECHANISM_QUERY_ALL}} property is given).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months