[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)
9 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)
9 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)
9 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)
9 years
[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-384:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Server does wrongly reference a list of socket binding groups
> -------------------------------------------------------------
>
> Key: WFCORE-384
> URL: https://issues.jboss.org/browse/WFCORE-384
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: luck3y
> Fix For: 2.0.0.Beta1
>
>
> hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups
> [10:59am] hbraun: shouldn't that be a a single socket binding instead?
> [11:00am] emuckenhuber: oh... yeah
> [11:00am] hbraun: maybe it's just the description that's wrong
> [11:00am] emuckenhuber: that sounds similar to the jvm thing we had
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (WFCORE-392) Stack trace improvements, summarize the things that broke to make them not so intimidating
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-392?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-392:
------------------------------------
Fix Version/s: (was: 1.0.0.CR1)
> Stack trace improvements, summarize the things that broke to make them not so intimidating
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-392
> URL: https://issues.jboss.org/browse/WFCORE-392
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jim Tyrrell
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: eap6-ux
> Attachments: log.txt
>
>
> See the typical attached stack dump:
> It would be nice if the stack dump could include all of the information above as a summary as shown below, basically just the first lines of the errors w/o the whole stack dump:
> 11:51:45,391 INFO [org.jboss.as.server.controller] (HttpManagementService-threads - 5) Deployment of "SpringWAR.war" was rolled back with failure message {"Failed services" => {"jboss.web.deployment.default-host./SpringWAR" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context"}}
> 11:51:45,392 INFO [org.jboss.as.controller] (HttpManagementService-threads - 5) Service status report
> Services which failed to start:
> service jboss.web.deployment.default-host./SpringWAR: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./SpringWAR: failed to start context
> 11:51:45,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment SpringWAR.war in 26ms
> 11:51:45,417 Error Summary of Exceptions in deployment:
> - [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> - [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
> - ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
> - [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
> - [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
> ERROR Scroll up to see more info...
> Or
> 11:51:45,417 Error Summary of Exceptions in deployment:
> [1] [org.springframework.web.context.ContextLoader] (MSC service thread 1-5) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> [2] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbossQueue' defined in class path resource [applicationContextServices.xml]: Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: queue/B -- service jboss.naming.context.java.queue.B
> [3] [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
> [4] ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/SpringWAR] startup failed due to previous errors
> [5] [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SpringWAR]] (MSC service thread 1-5) Closing Spring root WebApplicationContext
> [6] [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./SpringWAR:
> ERROR Scroll up to see more info...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.
by Federico Bertola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ]
Federico Bertola commented on DROOLS-775:
-----------------------------------------
After further investigation (profiling) I found that if I stub the {{ClassObjectTypeConf#checkPropertyListenerSupport}} method (which uses reflection internally) I experience a noticeable performance increase. The field {{supportsPropertyListeners}} is not used anywhere else. There's something I'm missing?
> Performance degradation with objects with many properties in working memory.
> ----------------------------------------------------------------------------
>
> Key: DROOLS-775
> URL: https://issues.jboss.org/browse/DROOLS-775
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final
> Environment: Ubuntu 14.10 x64, jdk 8
> Reporter: Federico Bertola
> Assignee: Mario Fusco
> Labels: regression
> Attachments: drools-test.zip
>
>
> I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate.
> For example, after 100k iterations:
> droosl 5.0.1
> -- Meters ----------------------------------------------------------------------
> org.acme.test.drools5.DroolsPerformance.analized
> count = 100000
> mean rate = 549.27 events/second
> ...
> drools 6.2.0.Final
> -- Meters ----------------------------------------------------------------------
> org.acme.test.drools6.DroolsPerformance.analized
> count = 100000
> mean rate = 198.58 events/second
> ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (WFCORE-393) Clone a profile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-393:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Clone a profile
> ---------------
>
> Key: WFCORE-393
> URL: https://issues.jboss.org/browse/WFCORE-393
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 2.0.0.Beta1
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-401:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Consider using a "describe" notion for providing the model to slaves on registration
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-401
> URL: https://issues.jboss.org/browse/WFCORE-401
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 2.0.0.Beta1
>
>
> When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave.
> Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC.
> This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years