June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1612) Allow applying the same configuration changes to multiple Standalone nodes

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-1612: ------------------------------------- Well, than just connect to each standalone server separately and apply changes, I don't see what could we do to help with this kind of scenario. you need some coordinator "server" which pushes updates to all standalone servers. Our ootb solution for that is domain mode, but with standalone you can do it with some other server / tool that does that for you. maybe ansible or something like that. > Allow applying the same configuration changes to multiple Standalone nodes > -------------------------------------------------------------------------- > > Key: WFCORE-1612 > URL: https://issues.jboss.org/browse/WFCORE-1612 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Sebastian Łaskawiec > Assignee: Brian Stansberry > > I would like to request a supporting configuration changes to multiple standalone nodes the same way as currently DMR in domain mode works. > The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case. > In Infinispan project we use DMR to propagate configuration changes to all nodes in the cluster (e.g. adding a cache, changing it etc). When considering Cloud deployment we use Standalone mode. It would be nice to find a way to propagate configuration changes to all servers the same way as we do in Domain mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6706) Domain mode stack trace on session invalidate

by Robert Smith (JIRA)

[ https://issues.jboss.org/browse/WFLY-6706?page=com.atlassian.jira.plugin.... ] Robert Smith commented on WFLY-6706: ------------------------------------ Any new status on this yet? > Domain mode stack trace on session invalidate > --------------------------------------------- > > Key: WFLY-6706 > URL: https://issues.jboss.org/browse/WFLY-6706 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Web (Undertow) > Affects Versions: 9.0.2.Final > Reporter: Robert Smith > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6697) @PreDestroy beans not called when performing disable in domain mode

by Robert Smith (JIRA)

[ https://issues.jboss.org/browse/WFLY-6697?page=com.atlassian.jira.plugin.... ] Robert Smith commented on WFLY-6697: ------------------------------------ Any status on this issue yet? > @PreDestroy beans not called when performing disable in domain mode > ------------------------------------------------------------------- > > Key: WFLY-6697 > URL: https://issues.jboss.org/browse/WFLY-6697 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.2.Final > Reporter: Robert Smith > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1616) ServerSuspendHandler tries to do step completion and rollback handling in a different thread

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1616?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1616: ------------------------------------------ [~swd847] I'm not sure what semantics you wanted here. Was it to have the management op block until suspend is done (however long that may be), and thus support rolling back regardless of how long suspend takes? Or was it to support rollback only for the 1) case, where the suspend is immediate? Blocking sounds better, although potentially indefinite blocking with the management lock held is a concern. > ServerSuspendHandler tries to do step completion and rollback handling in a different thread > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1616 > URL: https://issues.jboss.org/browse/WFCORE-1616 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > > ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a different thread. The OperationContext is not intended to be invoked from multiple threads in this way. > 3 things can happen with this setup: > 1) There is no activity preventing suspend, so the suspend controller immediately calls back to the OperationListener on the thread that's handling the operation. So then things work fine. > 2) There is something that prevents synchronous suspend (i.e. user activity) so then the OperationListener gets invoked later by another thread. The completeStep call registers a rollback handler that will never get called because the op is already done. No harm, no foul unless the operation rolled back. > 3) Same as 2) but the OperationListener gets invoked later by another thread while the mgmt op is still executing and somehow something goes wrong, since AbstractOperationContext.Step is not written for concurrent modification. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6756) Cluster failover doesn't work on linux when network is disabled on a node

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6756?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6756: -------------------------------------- Assignee: Paul Ferraro (was: Jason Greene) > Cluster failover doesn't work on linux when network is disabled on a node > ------------------------------------------------------------------------- > > Key: WFLY-6756 > URL: https://issues.jboss.org/browse/WFLY-6756 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > > Failover works when a node is stopped from Admin console. It also works when you press Ctrl + C to stop services on that node. It just doesn't work when you try to disable the network on the node and this disabling also results in hampering of application functionality on the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6756) Cluster failover doesn't work on linux when network is disabled on a node

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6756?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-6756: ---------------------------------------- Please don't touch the Priority field. > Cluster failover doesn't work on linux when network is disabled on a node > ------------------------------------------------------------------------- > > Key: WFLY-6756 > URL: https://issues.jboss.org/browse/WFLY-6756 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > > Failover works when a node is stopped from Admin console. It also works when you press Ctrl + C to stop services on that node. It just doesn't work when you try to disable the network on the node and this disabling also results in hampering of application functionality on the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6756) Cluster failover doesn't work on linux when network is disabled on a node

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6756?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6756: ----------------------------------- Component/s: Clustering > Cluster failover doesn't work on linux when network is disabled on a node > ------------------------------------------------------------------------- > > Key: WFLY-6756 > URL: https://issues.jboss.org/browse/WFLY-6756 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jason Greene > > Failover works when a node is stopped from Admin console. It also works when you press Ctrl + C to stop services on that node. It just doesn't work when you try to disable the network on the node and this disabling also results in hampering of application functionality on the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6756) Cluster failover doesn't work on linux when network is disabled on a node

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6756?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6756: ----------------------------------- Priority: Major (was: Blocker) > Cluster failover doesn't work on linux when network is disabled on a node > ------------------------------------------------------------------------- > > Key: WFLY-6756 > URL: https://issues.jboss.org/browse/WFLY-6756 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Jason Greene > > Failover works when a node is stopped from Admin console. It also works when you press Ctrl + C to stop services on that node. It just doesn't work when you try to disable the network on the node and this disabling also results in hampering of application functionality on the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1616) ServerSuspendHandler tries to do step completion and rollback handling in a different thread

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1616?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1616: ------------------------------------------ https://github.com/bstansberry/wildfly-core/commit/f3ee7eea232c0517bf4be3... adds the missing standard assert that AbstractOperationContext uses on other methods to ensure that only valid threads are invoking on it. This will cause the 2) and 3) cases from the JIRA description to fail. https://ci.wildfly.org/viewLog.html?buildId=19472&tab=buildResultsDiv&bui... is a test run that I expect to fail due to this. > ServerSuspendHandler tries to do step completion and rollback handling in a different thread > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1616 > URL: https://issues.jboss.org/browse/WFCORE-1616 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > > ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a different thread. The OperationContext is not intended to be invoked from multiple threads in this way. > 3 things can happen with this setup: > 1) There is no activity preventing suspend, so the suspend controller immediately calls back to the OperationListener on the thread that's handling the operation. So then things work fine. > 2) There is something that prevents synchronous suspend (i.e. user activity) so then the OperationListener gets invoked later by another thread. The completeStep call registers a rollback handler that will never get called because the op is already done. No harm, no foul unless the operation rolled back. > 3) Same as 2) but the OperationListener gets invoked later by another thread while the mgmt op is still executing and somehow something goes wrong, since AbstractOperationContext.Step is not written for concurrent modification. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1616) ServerSuspendHandler tries to do step completion and rollback handling in a different thread

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1616?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1616: ------------------------------------- Description: ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a different thread. The OperationContext is not intended to be invoked from multiple threads in this way. 3 things can happen with this setup: 1) There is no activity preventing suspend, so the suspend controller immediately calls back to the OperationListener on the thread that's handling the operation. So then things work fine. 2) There is something that prevents synchronous suspend (i.e. user activity) so then the OperationListener gets invoked later by another thread. The completeStep call registers a rollback handler that will never get called because the op is already done. No harm, no foul unless the operation rolled back. 3) Same as 2) but the OperationListener gets invoked later by another thread while the mgmt op is still executing and somehow something goes wrong, since AbstractOperationContext.Step is not written for concurrent modification. was: ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a different thread. The OperationContext is not intended to be invoked from multiple threads in this way. 4 things can happen with this setup: 1) There is no activity preventing suspend, so the suspend controller immediately calls back to the OperationListener on the thread that's handling the operation. So then things work fine. 2) There is something that prevents synchronous suspend (i.e. user activity) so then the OperationListener gets invoked later by another thread. The completeStep call registers a rollback handler that will never get called because the op is already done. No harm, no foul unless the operation rolled back. 3) Same as 2) but the OperationListener gets invoked later by another thread while the mgmt op is still executing and somehow something goes wrong, since AbstractOperationContext.Step is not written for concurrent modification. 4) Same as 2) but assertions are enabled and the OperationContext rejects the call with an AssertionError, impacting the SuspendController functionality. > ServerSuspendHandler tries to do step completion and rollback handling in a different thread > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1616 > URL: https://issues.jboss.org/browse/WFCORE-1616 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > > ServerSuspendHandler is calling OperationContext.completeStep() and passing in a rollback handler from a org.jboss.as.server.suspend.OperationListener that may be invoked by a different thread. The OperationContext is not intended to be invoked from multiple threads in this way. > 3 things can happen with this setup: > 1) There is no activity preventing suspend, so the suspend controller immediately calls back to the OperationListener on the thread that's handling the operation. So then things work fine. > 2) There is something that prevents synchronous suspend (i.e. user activity) so then the OperationListener gets invoked later by another thread. The completeStep call registers a rollback handler that will never get called because the op is already done. No harm, no foul unless the operation rolled back. > 3) Same as 2) but the OperationListener gets invoked later by another thread while the mgmt op is still executing and somehow something goes wrong, since AbstractOperationContext.Step is not written for concurrent modification. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016