[JBoss JIRA] (WFCORE-1630) Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1630?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1630:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1644, https://github.com/wildfly/wildfly-core/pull/1608 (was: https://github.com/wildfly/wildfly-core/pull/1644)
> Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1630
> URL: https://issues.jboss.org/browse/WFCORE-1630
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 2.2.0.CR5, 3.0.0.Alpha3
>
>
> When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
> {noformat}
> [Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1630) Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1630:
-----------------------------------
Summary: Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
Key: WFCORE-1630
URL: https://issues.jboss.org/browse/WFCORE-1630
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.10.Final
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
{noformat}
[Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1629) Potential NullPointerException when registering the management console redirect service
by George Gastaldi (JIRA)
George Gastaldi created WFCORE-1629:
---------------------------------------
Summary: Potential NullPointerException when registering the management console redirect service
Key: WFCORE-1629
URL: https://issues.jboss.org/browse/WFCORE-1629
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: George Gastaldi
Assignee: Brian Stansberry
While creating a WildFly Swarm Fraction that exposes the management console, I debugged ConsoleMode and found out that a NullPointerException is thrown in the {{findConsoleVersions}} methods. That's because the {{module.path}} returns {{null}} (as specified in the default value in this same method).
A simple null check is enough to fix it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6773) Provide ability to start/stop Data Source creation without restart of server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6773?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6773:
----------------------------------------
[~maeste] He has a reload there in between removing the DS and removing the driver. The fact that the driver remove responds with ""response-headers" => {"process-state" => "reload-required"}" is suspicious though.
Use the high level CLI "reload" command instead of the low level ":reload()" operation. With the command the CLI waits for the server to complete reload; with the low level op the reload is triggered and the server responds saying that it has been triggered but that's it. If your changes are in a CLI script it's possible the driver remove is happening before the reload actually happens. That seems unlikely but it's the only thing I can think of and regardless, the high level command is the way to do a reload.
> Provide ability to start/stop Data Source creation without restart of server
> ----------------------------------------------------------------------------
>
> Key: WFLY-6773
> URL: https://issues.jboss.org/browse/WFLY-6773
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Ramesh Reddy
> Assignee: Stefano Maestri
>
> Currently in WF 10, where a data source is created / removed using the CLI the "reload-status" is set to "requires restart", based how the resource is expected to be managed in WF.
> h3. Why We need it?
> In Teiid, it is common practice to add/remove data sources dynamically and restarting server will affect performance and usability severely.
> * Because delete/re-add is in Teiid's workflow to manage a data sources and when we have to restart we loose the whole state of the virtual database. That means we need re-establish runtime status. For example, all the existing sessions will be killed.
> * Runtime environment are often shared, that could kill other person's tasks in flight leaving them hanging with errors.
> * Every time data source starts we fetch metadata from the source, this is very expensive operation.
> * With multi-source feature, it is a feature that user dynamically brings in/out sources as they show up on their dashboard, it would be not possible to support this feature.
> * This is a change of behavior from earlier versions of the EAP, our users and customers rely on this feature
> As per Teiid project is concerned, we consider this is regression on WF and thus a bug.
> h3. Proposed Solution
> [~brian.stansberry] suggested the WF management practices here in this document https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Apply...
> Based on this the conclusion is that Data Sources, is developed under "all-services" paradigm, not under "resource-services" paradigm, where a explicit header from client to whether to restart or not can avoid having to "reload" the server when a new DS is added or removed. We understand the nature of service dependencies in WF, and how this can affect the other dependent services, but we verified that Teiid will not have those side effects as we designed. Since these sources are effectively exclusively defined for Teiid should not interfere with others. Also, since the request is explicit, should not affect current behavior.
> h3. Workarounds Considered
> Since this highly dependent on configuration based data source creation, we can opt to a deployment based data source creation (-ds.xml), however GSS is quick to dismiss this as this not supported feature.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6781 at 6/29/16 2:13 PM:
-------------------------------------------------------------
OK - so this is a JMS failover question. Reassigning to JMS team.
In the future, please be more specific in your jira description.
was (Author: pferraro):
OK - so this is a JMS failover question. Reassigning to JMS team.
> 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
>
> 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, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-6781:
----------------------------------
Assignee: Jeff Mesnil (was: Paul Ferraro)
> 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
>
> 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, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6781:
-------------------------------
Component/s: JMS
(was: Clustering)
> 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: Paul Ferraro
> Priority: Blocker
>
> 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, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6781:
------------------------------------
OK - so this is a JMS failover question. Reassigning to JMS team.
> 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: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Blocker
>
> 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, 3 months