[JBoss JIRA] (WFCORE-1629) Potential NullPointerException when registering the management console redirect service
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1629?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1629:
----------------------------------------
Assignee: George Gastaldi (was: Brian Stansberry)
> 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
> Affects Versions: 2.0.10.Final
> Reporter: George Gastaldi
> Assignee: George Gastaldi
>
> 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)
7 years, 9 months
[JBoss JIRA] (WFLY-6794) Upgrade JGroups to 3.6.10.Final
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6794:
----------------------------------
Summary: Upgrade JGroups to 3.6.10.Final
Key: WFLY-6794
URL: https://issues.jboss.org/browse/WFLY-6794
Project: WildFly
Issue Type: Component Upgrade
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Priority: Blocker
Fix For: 10.1.0.Final
Contains important regression fixes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-351:
-----------------------------------------
OK, so that sounds good for the "revert to snapshot" use case, as we want the base file updated. It's not good for a use case where the user is really trying to completely switch the server to another file. But thinking about it more I think that's fine and is just a documentation issue. The purpose of the feature is to bulk update the running config from some other document (either a snapshot or standalone2.xml that they prepared for some reason.) It is not meant to be a complete switch of the server to a different config file. A complete switch requires stopping the server and starting again with new arguments.
IMO the CLI "reload --help" output and the read-operation-description(name=reload) output need to be clearer about this.
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 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 6/30/16 12:05 PM:
------------------------------------------------------------------
Attached are the logs before and after incorporating the failover testing scenario for both RC and SL.
BeforeFailover logs : Are when Node1 and Node2 are running and working correctly and JMS messages is processed.
AfterFailover logs: Are when Node2 is powered off and Node1 is running but JMS messages on Node1 is not getting processed by SL on Node1.
Note : The workaround we have found is to restart both Node1 and Node2. Just powering on Node2 is not enough to make it work as expected.
[^attachment-name.zip]
was (Author: kpreeta12):
Attached are the logs before and after testing failover for both RC and SL.
BeforeFailover logs : Are when Node1 and Node2 are running and working correctly and JMS messages is processed.
AfterFailover logs: Are when Node2 is powered off and Node1 is running but JMS messages on Node1 is not getting processed by SL on Node1.
Note : The workaround we have found is to restart both Node1 and Node2. Just powering on Node2 is not enough to make it work as expected.
[^attachment-name.zip]
> 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)
7 years, 9 months
[JBoss JIRA] (WFLY-6793) Batch subsystem cannot be removed with a remove operation
by James Perkins (JIRA)
James Perkins created WFLY-6793:
-----------------------------------
Summary: Batch subsystem cannot be removed with a remove operation
Key: WFLY-6793
URL: https://issues.jboss.org/browse/WFLY-6793
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: James Perkins
Assignee: James Perkins
The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked.
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration",
"rolled-back" => true,
"response-headers" => undefined
}
{code}
The batch configuration dependency needs to be removed before the its dependencies are removed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFCORE-351:
-----------------------------------
It seems to be the original file.
In core, I copied standalone.xml to standalone2.xml.
I then start using standalone.xml, and execute these commands:
{code}
/system-property=test:add(value=a)
{code}
standalone.xml gets updated as expected
{code}
reload --server-config=standalone2.xml
{code}
This now overwrites standalone.xml so there is no property 'test' there (nor in standalone2.xml)
{code}
/system-property=test:add(value=b)
{code}
standalone.xml contains the 'test' property, but standalone2.xml does not.
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 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 updated WFLY-6781:
-----------------------------------
Attachment: host.Node2.xml
host.Node1.xml
domain.Node1.xml
Also attached are the domain.xml and host.xml
> 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)
7 years, 9 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:
----------------------------------------
Attached are the logs before and after testing failover for both RC and SL.
BeforeFailover logs : Are when Node1 and Node2 are running and working correctly and JMS messages is processed.
AfterFailover logs: Are when Node2 is powered off and Node1 is running but JMS messages on Node1 is not getting processed by SL on Node1.
Note : The workaround we have found is to restart both Node1 and Node2. Just powering on Node2 is not enough to make it work as expected.
[^attachment-name.zip]
> 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: 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)
7 years, 9 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 updated WFLY-6781:
-----------------------------------
Attachment: server.SL.Node1.BeforeFailover.log
server.SL.Node1.AfterFailover.log
server.RC.Node2.BeforeFailover.log
server.RC.Node2.AfterFailover.log
server.RC.Node1.BeforeFailover.log
server.RC.Node1.AfterFailover.log
> 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: 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)
7 years, 9 months