[JBoss JIRA] (WFLY-6762) Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6762:
-----------------------------------
Description:
In your mail related to WFLY-6749 you have said the below :-
**The default stack contains the following failure detection protocols:
FD_SOCK
FD_ALL
These protocols are described here:
http://www.jgroups.org/manual/index.html#FailureDetection
I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
e.g.
<protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
**************************************************************************************************
Thanks for the quick response on WFLY-6749.
Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
https://developer.jboss.org/thread/238135?tstart=0
Thanks,
Preeta
was:
In your mail related to WFLY-6749 you has said the below :-
**The default stack contains the following failure detection protocols:
FD_SOCK
FD_ALL
These protocols are described here:
http://www.jgroups.org/manual/index.html#FailureDetection
I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
e.g.
<protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
**************************************************************************************************
Thanks for the quick response on WFLY-6749.
Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
https://developer.jboss.org/thread/238135?tstart=0
Thanks,
Preeta
> Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> In your mail related to WFLY-6749 you have said the below :-
> **The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> **************************************************************************************************
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
> Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
> https://developer.jboss.org/thread/238135?tstart=0
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1379) service.bat points user to wrong directory
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1379?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1379:
-------------------------------------
Well, than this is different issue than one described here, this issue only talks about bug in documentation noting else.
please create separate issue for this.
> service.bat points user to wrong directory
> ------------------------------------------
>
> Key: WFCORE-1379
> URL: https://issues.jboss.org/browse/WFCORE-1379
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.10.Final
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
> Priority: Trivial
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Running service.bat from the docs/contrib/scripts/service dir tells user to run the script under bin/service*s* but the binary paths to the services expects bin/service, resulting in service install failure with file not found
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1622) Worker section in IO subsystem does not allow expressions for io-threads and task-max-threads attributes
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1622?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1622:
--------------------------------
Component/s: IO
> Worker section in IO subsystem does not allow expressions for io-threads and task-max-threads attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1622
> URL: https://issues.jboss.org/browse/WFCORE-1622
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Affects Versions: 1.0.2.Final
> Reporter: Umesh Kudale
> Assignee: Tomaz Cerar
>
> I want to dynamically configure following section in IO subsystem in standalone.xml of wildfly:
> <worker name="default" io-threads="100" task-max-threads="1000"/>
> Here if I do something like:
> <worker name="default" io-threads="${my.io.threads:100}" task-max-threads="${my.task.max.threads:1000}"/>
> And pass parameters as -Dmy.io.threads, -Dmy.task.max.threads while starting wildfly server, it's failing to parse standalone.xml with following exception:
> _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:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] Caused by: java.lang.NumberFormatException: For input string: "${my.io.threads:100}" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_45] at java.lang.Integer.parseInt(Integer.java:569) [rt.jar:1.8.0_45] at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45] at org.jboss.dmr.StringModelValue.asInt(StringModelValue.java:139) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final] at org.jboss.dmr.ModelNode.asInt(ModelNode.java:240) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final] at org.jboss.as.controller.AttributeParser.parse(AttributeParser.java:116) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser.parse(AttributeParser.java:82) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser$DiscardOldDefaultValueParser.parse(AttributeParser.java:177) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser.parseAndSetParameter(AttributeParser.java:61) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:83) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:135) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:107) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.wildfly.extension.io.IOSubsystemParser_1_0.readElement(IOSubsystemParser_1_0.java:71) at org.wildfly.extension.io.IOSubsystemParser_1_0.readElement(IOSubsystemParser_1_0.java:41) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:458) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] ... 3 more_
> This section should allow expressions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1622) Worker section in IO subsystem does not allow expressions for io-threads and task-max-threads attributes
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1622?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1622:
--------------------------------
Affects Version/s: 1.0.2.Final
> Worker section in IO subsystem does not allow expressions for io-threads and task-max-threads attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1622
> URL: https://issues.jboss.org/browse/WFCORE-1622
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 1.0.2.Final
> Reporter: Umesh Kudale
> Assignee: Tomaz Cerar
>
> I want to dynamically configure following section in IO subsystem in standalone.xml of wildfly:
> <worker name="default" io-threads="100" task-max-threads="1000"/>
> Here if I do something like:
> <worker name="default" io-threads="${my.io.threads:100}" task-max-threads="${my.task.max.threads:1000}"/>
> And pass parameters as -Dmy.io.threads, -Dmy.task.max.threads while starting wildfly server, it's failing to parse standalone.xml with following exception:
> _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:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] Caused by: java.lang.NumberFormatException: For input string: "${my.io.threads:100}" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_45] at java.lang.Integer.parseInt(Integer.java:569) [rt.jar:1.8.0_45] at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45] at org.jboss.dmr.StringModelValue.asInt(StringModelValue.java:139) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final] at org.jboss.dmr.ModelNode.asInt(ModelNode.java:240) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final] at org.jboss.as.controller.AttributeParser.parse(AttributeParser.java:116) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser.parse(AttributeParser.java:82) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser$DiscardOldDefaultValueParser.parse(AttributeParser.java:177) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser.parseAndSetParameter(AttributeParser.java:61) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:83) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:135) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:107) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.wildfly.extension.io.IOSubsystemParser_1_0.readElement(IOSubsystemParser_1_0.java:71) at org.wildfly.extension.io.IOSubsystemParser_1_0.readElement(IOSubsystemParser_1_0.java:41) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:458) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] ... 3 more_
> This section should allow expressions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1622) Worker section in IO subsystem does not allow expressions for io-threads and task-max-threads attributes
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1622?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1622:
-----------------------------------
Assignee: Tomaz Cerar
> Worker section in IO subsystem does not allow expressions for io-threads and task-max-threads attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1622
> URL: https://issues.jboss.org/browse/WFCORE-1622
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Umesh Kudale
> Assignee: Tomaz Cerar
>
> I want to dynamically configure following section in IO subsystem in standalone.xml of wildfly:
> <worker name="default" io-threads="100" task-max-threads="1000"/>
> Here if I do something like:
> <worker name="default" io-threads="${my.io.threads:100}" task-max-threads="${my.task.max.threads:1000}"/>
> And pass parameters as -Dmy.io.threads, -Dmy.task.max.threads while starting wildfly server, it's failing to parse standalone.xml with following exception:
> _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:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] Caused by: java.lang.NumberFormatException: For input string: "${my.io.threads:100}" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_45] at java.lang.Integer.parseInt(Integer.java:569) [rt.jar:1.8.0_45] at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45] at org.jboss.dmr.StringModelValue.asInt(StringModelValue.java:139) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final] at org.jboss.dmr.ModelNode.asInt(ModelNode.java:240) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final] at org.jboss.as.controller.AttributeParser.parse(AttributeParser.java:116) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser.parse(AttributeParser.java:82) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser$DiscardOldDefaultValueParser.parse(AttributeParser.java:177) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.AttributeParser.parseAndSetParameter(AttributeParser.java:61) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:83) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:135) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:107) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] at org.wildfly.extension.io.IOSubsystemParser_1_0.readElement(IOSubsystemParser_1_0.java:71) at org.wildfly.extension.io.IOSubsystemParser_1_0.readElement(IOSubsystemParser_1_0.java:41) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:458) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final] ... 3 more_
> This section should allow expressions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6762) Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6762:
----------------------------------------
Just to elaborate on our issues. The network disabling on VM for failover testing is not working for Wildfly cluster on Linux environment as well as Windows environment.
The power off of VM for failover testing is working on Linux environment but not working on windows environment of wildfly cluster.
Could you also explain the reason for the above?
Thanks,
Preeta
> Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> In your mail related to WFLY-6749 you has said the below :-
> **The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> **************************************************************************************************
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
> Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
> https://developer.jboss.org/thread/238135?tstart=0
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6762) Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6762:
----------------------------------------
Thanks Paul. We have configured UDP based multicast for Ehcache -Cache replication for Wildfly cluster. This uses the jgroups.
Below is the udp.xml.
<!--
Default stack using IP multicasting. It is similar to the "udp"
stack in stacks.xml, but doesn't use streaming state transfer and flushing
author: Bela Ban
-->
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
<UDP
mcast_port="${jgroups.udp.mcast_port:45588}"
ip_ttl="4"
tos="8"
ucast_recv_buf_size="5M"
ucast_send_buf_size="5M"
mcast_recv_buf_size="5M"
mcast_send_buf_size="5M"
max_bundle_size="64K"
max_bundle_timeout="30"
enable_diagnostics="true"
thread_naming_pattern="cl"
timer_type="new3"
timer.min_threads="2"
timer.max_threads="4"
timer.keep_alive_time="3000"
timer.queue_max_size="500"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="10000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="discard"/>
<PING />
<MERGE3 max_interval="30000"
min_interval="10000"/>
<FD_SOCK/>
<FD_ALL/>
<VERIFY_SUSPECT timeout="1500" />
<BARRIER />
<pbcast.NAKACK2 xmit_interval="500"
xmit_table_num_rows="100"
xmit_table_msgs_per_row="2000"
xmit_table_max_compaction_time="30000"
max_msg_batch_size="500"
use_mcast_xmit="true"
discard_delivered_msgs="true"/>
<UNICAST3 xmit_interval="500"
xmit_table_num_rows="100"
xmit_table_msgs_per_row="2000"
xmit_table_max_compaction_time="60000"
conn_expiry_timeout="0"
max_msg_batch_size="500"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="4M"/>
<pbcast.GMS print_local_addr="true" join_timeout="2000"
view_bundling="true"/>
<UFC max_credits="2M"
min_threshold="0.4"/>
<MFC max_credits="2M"
min_threshold="0.4"/>
<FRAG2 frag_size="60K" />
<RSVP resend_interval="2000" timeout="10000"/>
<pbcast.STATE_TRANSFER />
<!-- pbcast.FLUSH /-->
</config>
> Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> In your mail related to WFLY-6749 you has said the below :-
> **The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> **************************************************************************************************
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment.
> Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se...
> https://developer.jboss.org/thread/238135?tstart=0
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months