[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, 4 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, 4 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, 4 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, 4 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, 4 months
[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1614:
----------------------------------------------
I have resync the PR with this additional fix.
> Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1614
> URL: https://issues.jboss.org/browse/WFCORE-1614
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha3
>
> Attachments: test.cli
>
>
> We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output.
> For example, the "ls -l" command output would be:
> [standalone@localhost:9990 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type STANDALONE STRING
> management-major-version 5 INT
> management-micro-version 0 INT
> management-minor-version 0 INT
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a distinct SessionIdentifierCodec
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6778:
-------------------------------
Description:
Undertow exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. Thus, rather than installing a single SessionIdentifierCodec for the subsystem, we should install one instance per server.
was:
Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names.
> Each Undertow server should expose a distinct SessionIdentifierCodec
> --------------------------------------------------------------------
>
> Key: WFLY-6778
> URL: https://issues.jboss.org/browse/WFLY-6778
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Undertow exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
> Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. Thus, rather than installing a single SessionIdentifierCodec for the subsystem, we should install one instance per server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a distinct SessionIdentifierCodec
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6778:
-------------------------------
Summary: Each Undertow server should expose a distinct SessionIdentifierCodec (was: Each Undertow server should expose a unique instance-id)
> Each Undertow server should expose a distinct SessionIdentifierCodec
> --------------------------------------------------------------------
>
> Key: WFLY-6778
> URL: https://issues.jboss.org/browse/WFLY-6778
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
> Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a unique instance-id
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6778:
------------------------------------
@ctomc The fundamental problem is that we only install a single SessionIdentifierCodec for the subsystem, rather than a distinct SessionIdentifierCodec per server. I'll update the description to clarify.
> Each Undertow server should expose a unique instance-id
> -------------------------------------------------------
>
> Key: WFLY-6778
> URL: https://issues.jboss.org/browse/WFLY-6778
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct.
> Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months