June 2016 - jboss-jira - Jboss List Archives

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

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1616: ---------------------------------------- Summary: 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. 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. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121)

by Jorge Solorzano (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ] Jorge Solorzano updated WFCORE-1615: ------------------------------------ Description: To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh (was: This change is related to WFCORE-1121 Use script name for file related to Wildfly to allow multiple instances easily. To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh) > Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121) > -------------------------------------------------------------------------------- > > Key: WFCORE-1615 > URL: https://issues.jboss.org/browse/WFCORE-1615 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 3.0.0.Alpha2 > Reporter: Jorge Solorzano > Assignee: Tomaz Cerar > Priority: Trivial > > To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121)

by Jorge Solorzano (JIRA)

Jorge Solorzano created WFCORE-1615: --------------------------------------- Summary: Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121) Key: WFCORE-1615 URL: https://issues.jboss.org/browse/WFCORE-1615 Project: WildFly Core Issue Type: Enhancement Components: Scripts Affects Versions: 3.0.0.Alpha2 Reporter: Jorge Solorzano Assignee: Tomaz Cerar Priority: Trivial This change is related to WFCORE-1121 Use script name for file related to Wildfly to allow multiple instances easily. To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6757) Upgrade JBeret from 1.2.0.Final to 1.2.1.FInal

by James Perkins (JIRA)

James Perkins created WFLY-6757: ----------------------------------- Summary: Upgrade JBeret from 1.2.0.Final to 1.2.1.FInal Key: WFLY-6757 URL: https://issues.jboss.org/browse/WFLY-6757 Project: WildFly Issue Type: Component Upgrade Components: Batch Reporter: James Perkins Assignee: James Perkins Upgrade JBeret from 1.2.0.Final to 1.2.1.Final. -- 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 Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-6756?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-6756: ----------------------------------- Priority: Blocker (was: Major) > 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 > Priority: Blocker > > 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 Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-6756?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-6756: ----------------------------------- Affects Version/s: 8.2.0.Final > 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 > Priority: Blocker > > 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-1604) Fail-fast start up init.d scripts on error

by Jorge Solorzano (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1604?page=com.atlassian.jira.plugi... ] Jorge Solorzano updated WFCORE-1604: ------------------------------------ Description: Now that WildFly creates an startup-marker we can detect an error before timeout of the init.d startup scripts and detect if the error is from timeout or from an error in application server. was:Now that WildFly creates an startup-marker we can detect an error before timeout of the init.d startup scripts. > Fail-fast start up init.d scripts on error > ------------------------------------------ > > Key: WFCORE-1604 > URL: https://issues.jboss.org/browse/WFCORE-1604 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 3.0.0.Alpha1 > Environment: Debian/Ubuntu - Red Hat/Fedora > Reporter: Jorge Solorzano > Assignee: Tomaz Cerar > Priority: Optional > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Now that WildFly creates an startup-marker we can detect an error before timeout of the init.d startup scripts and detect if the error is from timeout or from an error in application server. -- 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 Preeta Kuruvilla (JIRA)

Preeta Kuruvilla created WFLY-6756: -------------------------------------- Summary: 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 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-1612) Allow applying the same configuration changes to multiple Standalone nodes

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ] Sebastian Łaskawiec commented on WFCORE-1612: --------------------------------------------- Thanks [~brian.stansberry] for the input! Shall I close this issue then a duplicate of https://issues.jboss.org/browse/WFCORE-433 than? I'm not sure if using GIT will be a good fit (but on the other hand I can't propose anything better). If I remember correctly, Ben mentioned that once a GIT volume is mounted into the OpenShift's Pod, it won't get any index updates. If a refresh is needed we would need to restart it. > 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] (WFCORE-1612) Allow applying the same configuration changes to multiple Standalone nodes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1612: ------------------------------------------ The discussion on and around WFCORE-433 is basically on this topic. I mentioned on our way to dinner Vancouver that I saw the ability of WildFly Core to react to a signal and update its running configuration based on a re-read of the persistent store being the core functionality inside core itself. [~ehugonnet] is looking at that; I hope it will be the main focus once his work on managed exploded deployments is done. The mechanism for propagating the shared content (config plus content repo content) and for signaling the process that a change is present is a cloud infrastructure concern. I assume the initial one we'll concern ourselves with will be what xPaas decides on. Inputs seem to vary between git and ConfigMap, but either way we need to be able to react and update our running config. > 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

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