[JBoss JIRA] (WFCORE-317) Failed to start server when -backup -cached-dc are used together
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-317?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-317:
---------------------------------------
Assignee: luck3y
Ken, I'm assigning this as one of several in the general area of how various Host Controllers interact. We should look at them in total and come up with a strategy, not do them piecemeal.
> Failed to start server when -backup -cached-dc are used together
> ----------------------------------------------------------------
>
> Key: WFCORE-317
> URL: https://issues.jboss.org/browse/WFCORE-317
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Rok Bertoncelj
> Assignee: luck3y
>
> When starting a slave host controller with *-backup -cached-dc* at the same time, the servers fail to start. Tested with 7.1.1.Final and 7.1.2.Final-SNAPSHOT today.
> Also tried starting only with -backup first (starts OK) and then for the second time with both options, to make sure that cached configuration is already present if it would help, but it didn't.
> Host controller should determine availability of domain controller and either backup domain configuration or use the cached one if domain controller is unavailable.
> {code}
> 10:35:36,093 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.1.GA
> 10:35:36,176 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> 10:35:36,225 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" starting
> 10:35:36,612 WARN [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010930: Cannot load the domain model using using --backup
> 10:35:36,617 INFO [org.xnio] (MSC service thread 1-6) XNIO Version 3.0.3.GA
> 10:35:36,631 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.0.3.GA
> 10:35:36,649 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 3.2.4.GA
> 10:35:36,970 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010907: Failed to start server (server-one): java.util.NoSuchElementException: No child 'server-group' exists
> at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.host.controller.ModelCombiner.<init>(ModelCombiner.java:139) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.createManagedServer(ServerInventoryImpl.java:474) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:160) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:150) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:521) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.cleanStartServers(StartServersHandler.java:114) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.access$300(StartServersHandler.java:50) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler$1.execute(StartServersHandler.java:94) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.executeDirect(PrepareStepHandler.java:122) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:74) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.startServers(DomainModelControllerService.java:443) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:403) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> 10:35:36,989 INFO [org.jboss.as.remoting] (MSC service thread 1-8) JBAS017100: Listening on /127.0.0.1:29999
> 10:35:37,015 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010907: Failed to start server (server-two): java.util.NoSuchElementException: No child 'server-group' exists
> at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.host.controller.ModelCombiner.<init>(ModelCombiner.java:139) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.createManagedServer(ServerInventoryImpl.java:474) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:160) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:150) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:521) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.cleanStartServers(StartServersHandler.java:114) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.access$300(StartServersHandler.java:50) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler$1.execute(StartServersHandler.java:94) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.executeDirect(PrepareStepHandler.java:122) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:74) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.startServers(DomainModelControllerService.java:443) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:403) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> 10:35:37,082 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" (Host Controller) started in 1249ms - Started 11 of 11 services (0 services are passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-338) Auto-promotion of slave HC to master based on a shared lock
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-338?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-338:
-----------------------------------------
Ken, see my comment above. This particular approach may not be something we want, but I'm assigning it to you as it's related to the general topic of an HA Domain Controller.
> Auto-promotion of slave HC to master based on a shared lock
> -----------------------------------------------------------
>
> Key: WFCORE-338
> URL: https://issues.jboss.org/browse/WFCORE-338
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
>
> Implement an option for a properly configured slave HC to promote itself to master after acquiring an exclusive lock mediated via some persistent store shared between all HCs that are possibly master.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-324) Resolve startup dependency between master hostController and slave hostControllers.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-324?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-324:
---------------------------------------
Assignee: luck3y
Ken, I'm assigning this as one of several in the general area of how various Host Controllers interact. We should look at them in total and come up with a strategy, not do them piecemeal.
> Resolve startup dependency between master hostController and slave hostControllers.
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-324
> URL: https://issues.jboss.org/browse/WFCORE-324
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: karin k
> Assignee: luck3y
>
> *Current situation:*
> * The slave hostController can be started using option --cached-dc
> Result: the slave hostContoller will be started given that a local copy of the domain.xml (exact name domain.cached-remote.xml
> ) is available (created by a startup using -backup and an available master hostController)
> The slave hostController will never register itself towards the master domain hostController (regardless of whether the master domain controller is running during startup or will be started afterwards)
> * The slave hostController can be started without any option
> If the master hostController is not running during startup of the slave, the startup of the slave will fail.
> * The slave hostController can be started with option -backup
> If the master hostController is not running during startup of the slave, the startup of the slave will fail.
> If the master hostController is running, the slave will store a copy of the domain.xml locally.
> A successful startup of the whole domain is only possible when the hostControllers are started in the correct sequence (master hostController must be available when slave host Controllers are trying to register). From my point of view a successful startup means that all hostControllers can start successfully and additionally it is possible to manage the slave hostController by means of the master hostController.
> *Requirement*
> To let a JBoss domain act and started in the correct way (meaning central management is possible) the following should be fullfilled
> * If the master hostController is not running, the slave should still be able to start and work with its local copy of the domain.xml
> * If the master hostController is started after the slave hostController, the slave host controller should still be able to start successfully but should in parallel recognize when the master hostController is finally available and register itself
> * There should be the possiblity to store a local copy of the domain master hostController in parallel with the approach of starting up when the master hostController is not running (in this case the master domain.xml cannot be stored locally but anyway startup is possible).
> (see also https://issues.jboss.org/browse/AS7-4281)
> Regards
> Karin
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (REMJMX-91) AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-91?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved REMJMX-91.
------------------------------------
Resolution: Done
> AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions.
> ------------------------------------------------------------------------------------------------------------
>
> Key: REMJMX-91
> URL: https://issues.jboss.org/browse/REMJMX-91
> Project: Remoting JMX
> Issue Type: Bug
> Components: Notifications
> Affects Versions: 2.0.1.CR1
> Reporter: Bryan Varner
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.CR2
>
>
> I have a client using a handback object when events are received from remote JMX servers.
> The handback is a local object instance used in the client, and should be operated on as part of handling specific types of notifications. Rather than scoping this thing in my code all over the place, it was much easier to include it as a handback.
> This works _perfectly_ with the Oracle RMI client. When I try to use this code against JBoss remoting servers, I get (burried) ClassNotFound Exceptions referencing the name of my class.
> It appears that ClientConnection is sending serialized copies of the handback object to the server when a notificationListener is added... but why?
> https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jbo...
> Shouldn't the handback be local to the client?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (REMJMX-97) Optimise addNotificationListener so no handback needs to be sent.
by Darran Lofthouse (JIRA)
Darran Lofthouse created REMJMX-97:
--------------------------------------
Summary: Optimise addNotificationListener so no handback needs to be sent.
Key: REMJMX-97
URL: https://issues.jboss.org/browse/REMJMX-97
Project: Remoting JMX
Issue Type: Sub-task
Components: Connection
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 2.0.2.CR1
The following method call has been updated as a result of REMJMX-91 so null is sent for the handback - this is to retain compatibility with existing installations currently using version 2 of the protocol.
{code}
public void addNotificationListener(final ObjectName name, NotificationListener listener,
final NotificationFilter filter, final Object handback) throws InstanceNotFoundException, IOException {
{code}
In version 3 we can drop sending the handle.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (REMJMX-96) Create version 3 of the protocol
by Darran Lofthouse (JIRA)
Darran Lofthouse created REMJMX-96:
--------------------------------------
Summary: Create version 3 of the protocol
Key: REMJMX-96
URL: https://issues.jboss.org/browse/REMJMX-96
Project: Remoting JMX
Issue Type: Task
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 2.0.2.CR1
This is not a commitment to add version 3, that will be determined by the impact of other changes made.
This is more a case of tracking the changes that will need to be made in version 3 if it ever exists.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (REMJMX-91) AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-91?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on REMJMX-91:
----------------------------------------
The reason the handback was sent was consistency with the following method: -
{code}
void addNotificationListener(ObjectName name,
ObjectName listener,
NotificationFilter filter,
Object handback)
throws InstanceNotFoundException,
IOException
{code}
i.e. this method does need the handback sent to the server as it needs to be passed to another MBean.
But in the case identified here the NotificationListener is not sent to the server so we can also optimise and avoid sending the handle, should be a fairly trivial change without breaking backwards compatibility to stop sending the handle.
Note: Although this issue is addressing an error experienced on the server it is actually only the client side that needs the fix.
> AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions.
> ------------------------------------------------------------------------------------------------------------
>
> Key: REMJMX-91
> URL: https://issues.jboss.org/browse/REMJMX-91
> Project: Remoting JMX
> Issue Type: Bug
> Components: Notifications
> Affects Versions: 2.0.1.CR1
> Reporter: Bryan Varner
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.CR2
>
>
> I have a client using a handback object when events are received from remote JMX servers.
> The handback is a local object instance used in the client, and should be operated on as part of handling specific types of notifications. Rather than scoping this thing in my code all over the place, it was much easier to include it as a handback.
> This works _perfectly_ with the Oracle RMI client. When I try to use this code against JBoss remoting servers, I get (burried) ClassNotFound Exceptions referencing the name of my class.
> It appears that ClientConnection is sending serialized copies of the handback object to the server when a notificationListener is added... but why?
> https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jbo...
> Shouldn't the handback be local to the client?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months