[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-234:
------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 1.0.0.CR1)
> Inconsistent synchronization in ConfigurationFile
> -------------------------------------------------
>
> Key: WFCORE-234
> URL: https://issues.jboss.org/browse/WFCORE-234
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Fix For: 2.0.0.CR1
>
>
> ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir.
> The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot.
> The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-311:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-311
> URL: https://issues.jboss.org/browse/WFCORE-311
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: RH EL 6.3 - JBoss EAP 6.2
> Reporter: Riccardo Benvenuti
> Priority: Minor
> Fix For: 2.0.0.Beta1
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
> <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
> JAVA: /usr/java/jdk1.7.0_51/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly
> <domain-controller>
> <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-313) DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-313?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-313:
------------------------------------
Fix Version/s: 1.0.0.CR1
(was: 2.0.0.Alpha1)
> DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-313
> URL: https://issues.jboss.org/browse/WFCORE-313
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> When creating reply descriptions, DefaultOperationDescriptionProvider calls attributeDescriptionResolver.getOperationParameterDescription instead of attributeDescriptionResolver.getOperationReplyValueTypeDescription.
> A fix needs to not break compatibility for existing users of the incorrect behavior; i.e. call the correct method in a try block, catch any MissingResourceException, and if caught call the incorrect method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-313) DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-313?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-313:
------------------------------------
Fix Version/s: 2.0.0.Alpha1
(was: 1.0.0.CR1)
> DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-313
> URL: https://issues.jboss.org/browse/WFCORE-313
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Alpha1
>
>
> When creating reply descriptions, DefaultOperationDescriptionProvider calls attributeDescriptionResolver.getOperationParameterDescription instead of attributeDescriptionResolver.getOperationReplyValueTypeDescription.
> A fix needs to not break compatibility for existing users of the incorrect behavior; i.e. call the correct method in a try block, catch any MissingResourceException, and if caught call the incorrect method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-362) fix jvm management model for server and groups
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-362?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-362:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> fix jvm management model for server and groups
> ----------------------------------------------
>
> Key: WFCORE-362
> URL: https://issues.jboss.org/browse/WFCORE-362
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: luck3y
> Labels: rhq
> Fix For: 2.0.0.Beta1
>
>
> We need to update the JVM child resource definition for server-groups and servers to only allow a single JVM configuration (i.e. configuration=JVM) resource. Currently only the first configured VM is used, where the name is the reference to the corresponding host level JVM.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-366) Support timeout of management operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-366?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-366:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Support timeout of management operations
> ----------------------------------------
>
> Key: WFCORE-366
> URL: https://issues.jboss.org/browse/WFCORE-366
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> There have been various situations where bugs in WF or in user code have prevented management operations from completing, leaving the ModelController locked permanently, unless the process is stopped. There should be mechanism via which timeouts can be set.
> My proposal is to allow a timeout to be set via a management operation header. In addition, there will be a standard timeout that will apply if no header is present.
> The standard timeout will be quite lengthy, probably several minutes. The goal is to allow a management process to eventually auto-recover, not to do prompt detection of failures. Users can use the header if they wish prompt detection a failures. A short standard timeout runs the risk of false positives, particularly with large deployments.
> The meaning of this timeout is not to be an overall maximum time for operation execution. There would be no valid default for such a timeout in a managed domain, where the time it would take to roll out a change would depend on the size of the domain and the rollout plan.
> Rather, this timeout is meant to be the maximum period operation execution threads can block in various points. Blocking for longer than the timeout would result in operation failure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-380) Operations to read content from the content repository
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-380?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-380:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Operations to read content from the content repository
> ------------------------------------------------------
>
> Key: WFCORE-380
> URL: https://issues.jboss.org/browse/WFCORE-380
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
> Priority: Minor
> Fix For: 2.0.0.Beta1
>
>
> Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays.
> Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-378) Domain rollout operation timeouts
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-378?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-378:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Domain rollout operation timeouts
> ---------------------------------
>
> Key: WFCORE-378
> URL: https://issues.jboss.org/browse/WFCORE-378
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> Portion of the parent task related to rolling out changes to a domain.
> The expectation is that single process timeouts (WFLY-2741) will handle most failure conditions related to domain rollouts (e.g. if a single server hangs, preventing completion of the rollout, eventually that server will time out, allowing the domain wide rollout to continue.) Timeouts in the domain rollout code serve as a second line of defense:
> 1) In case of protocol or other problems that prevent the calling process learning about the timeout on the remote process
> 2) In case of bugs in the single process timeout handling on the remote process
> 3) In mixed domain cases where remote hosts are running previous versions and do not have the timeout function
> Potential places to add timeouts:
> DomainSlaveHandler->HostControllerUpdateTask.ProxyOperationListener.retrievePreparedOperation()
> -- where the master HC waits for responses from slaves
> RollingServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
> -- timeout here means 1 server didn't respond, but need to move on to next
> ConcurrentServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
> -- timeout here means none of the remaining servers have responded w/in the timeout
> DomainRolloutStepHandler.finalizeOp() -> future.get()
> ---- the ServerGroupUpdateTask should fail in the normal phase, so any timeout here would indicate a problem committing the tx or a comms problem getting back the response
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years