[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:
----------------------------------------------
Hi Petr, good catch. I have updated the PR. Thanks.
> 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.Alpha4
>
> 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, 10 months
[JBoss JIRA] (WFLY-6761) Wrong XAException return code when broker timeout is hit
by Dmitrii Tikhomirov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6761?page=com.atlassian.jira.plugin.... ]
Dmitrii Tikhomirov reassigned WFLY-6761:
----------------------------------------
Assignee: Dmitrii Tikhomirov (was: Chen Maoqian)
> Wrong XAException return code when broker timeout is hit
> --------------------------------------------------------
>
> Key: WFLY-6761
> URL: https://issues.jboss.org/browse/WFLY-6761
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Dmitrii Tikhomirov
> Priority: Minor
>
> By creating testcases for checking behavior of transaction timeout I've hit an issue of wrong error code being returned when broker transaction timeout is hit before TM transaction timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for processing ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but {{RBTIMEOUT}} would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific error return code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> "[XA_RBTIMEOUT]
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget about that branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no longer consider the calling thread associated with that resource manager (although it must consider the resource manager part of the transaction branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view corroborated by:
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread of control and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown
> {code}
> WARN [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:346)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
> at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
> at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
> at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at
> org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean$$$endpoint1.afterDelivery(Unknown
> Source)
> at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:321)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:932)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1045)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1628) Create module using 'module add' CLI command with absolute-path in resource-root element
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1628?page=com.atlassian.jira.plugi... ]
Martin Simka commented on WFCORE-1628:
--------------------------------------
I'll look into this one, I'll try to implement this with two params --resources and --absolute-resources as Brian suggests.
> Create module using 'module add' CLI command with absolute-path in resource-root element
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1628
> URL: https://issues.jboss.org/browse/WFCORE-1628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Martin Simka
> Assignee: Martin Simka
>
> MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
> {quote}
> resource-root's path previously only allowed resources within the module's directory, e.g.:
> <resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
> With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
> <resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
> {quote}
> {{module add}} command could have optional argument {{--copy-resources=(true|false)}} with default {{true}}, which would specify how new module will look like.
> * {{true}} copy files to the created module's directory = no change from how it works now.
> * {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
> Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1628) Create module using 'module add' CLI command with absolute-path in resource-root element
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1628?page=com.atlassian.jira.plugi... ]
Martin Simka reassigned WFCORE-1628:
------------------------------------
Assignee: Martin Simka (was: Alexey Loubyansky)
> Create module using 'module add' CLI command with absolute-path in resource-root element
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1628
> URL: https://issues.jboss.org/browse/WFCORE-1628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Martin Simka
> Assignee: Martin Simka
>
> MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
> {quote}
> resource-root's path previously only allowed resources within the module's directory, e.g.:
> <resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
> With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
> <resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
> {quote}
> {{module add}} command could have optional argument {{--copy-resources=(true|false)}} with default {{true}}, which would specify how new module will look like.
> * {{true}} copy files to the created module's directory = no change from how it works now.
> * {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
> Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
HornetQ cluster does not provide HA. For HA, replicated backup or shared store backup would have to be configured. HornetQ cluster just load balances messages across all active nodes. Every node in cluster has part of the messages for the given queue. Thus shutting down one node in cluster leads to "loss" of the messages. (of course of this node is started again and rejoins the HornetQ cluster then everything is ok again)
In your case there is no HornetQ cluster. All messages should be on node 1. I don't understand how SL.war could be disconnected if it's connected to node 1. Changing {{connection-ttl}} could at least show some warnings that something went wrong. Also could you double check sources of RC.war and SL.war that you do not ignore any exceptions?
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla edited comment on WFLY-6781 at 7/1/16 6:44 AM:
----------------------------------------------------------------
Thanks. I will set it to 60000ms.
Earlier in your comment, you also mentioned that - "no HornetQ cluster configured". Is that the reason why JMS is not able to handle the failover condition ?
Also to let you know, we have not implemented JMS replication for cluster.
Also would like to remind you that the failover by power off method works properly on Linux. Only its got issues (probably JMS related) on Windows OS.
-preeta
was (Author: kpreeta12):
Thanks. I will set it to 60000ms.
Earlier in your comment, you also mentioned that - "no HornetQ cluster configured". Is that the reason why JMS is not able to handle the failover condition ?
Also to let you know, we have not implemented JMS replication for cluster.
-preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla edited comment on WFLY-6781 at 7/1/16 6:35 AM:
----------------------------------------------------------------
Thanks. I will set it to 60000ms.
Earlier in your comment, you also mentioned that - "no HornetQ cluster configured". Is that the reason why JMS is not able to handle the failover condition ?
Also to let you know, we have not implemented JMS replication for cluster.
-preeta
was (Author: kpreeta12):
Thanks. I will set it to 60000ms.
Earlier in your comment, you also mentioned that - "no HornetQ cluster configured". Is that the reason why JMS is not able to handle the failover condition ?
-preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Thanks. I will set it to 60000ms.
Earlier in your comment, you also mentioned that - "no HornetQ cluster configured". Is that the reason why JMS is not able to handle the failover condition ?
-preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2065:
---------------------------
Fix Version/s: 4.1
(was: 4.0)
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months