November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3415) Cut the time to execute MBeanServerConnection.getMBeanCount()

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3415?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3415: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2930, https://github.com/wildfly/wildfly-core/pull/2961 (was: https://github.com/wildfly/wildfly-core/pull/2930) > Cut the time to execute MBeanServerConnection.getMBeanCount() > ------------------------------------------------------------- > > Key: WFCORE-3415 > URL: https://issues.jboss.org/browse/WFCORE-3415 > Project: WildFly Core > Issue Type: Enhancement > Components: JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha3 > > > The time it takes to count the mbeans associated with the jboss.as and jboss.as.expr domains is way too high, over a full second when the WildFly full standalone-full-ha.xml config is used, and potentially much higher if complex deployments are installed. See WFLY-9408. > This enhancement proposes doing two things to mitigate this: > 1) There is no point doing a full count of both jboss.as and jboss.as.expr as they are just 2 views on the same underlying resources. If both are present, count one and double it. > 2) Do not use RBAC to exclude from the count mbeans the user won't be allowed to see. They exist whether the user can see them or not. Simply count the resources. > Looking at the JMX specification (https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/JMX_1_4_specif...) I see nothing directly on the topic of the effect of any security checks on the result of getMBeanCount(). Section 12.1.2.4 "Permission Checking for Queries" clearly states that permission checks should remove mbeans that should not be visible according to the permission scheme from the query result, so definitely queries returning a subset of the entire mbean universe is contemplated. Now, that section is about security manager permissions, not our RBAC scheme, but it's the most on topic thing I see. > Doing these two things I can get the cost of a getMBeanCount() from around 1 second to under 10 ms. (Note the 1 sec figure is the first call; once the JVM optimizes the existing code it drops to under 500ms.) > The enhancement will also make it possible for custom Resource implementations to optimize things. For example a resource that represents a possibly large number of dynamic children could ask the system behind those children for a child count, rather that iterating over the children. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3429) DuplicateServiceException when artifact name equals to alias

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3429?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-3429. -------------------------------------- Assignee: (was: Jason Greene) Resolution: Rejected I agree with [~jaikiran]. Please re-open if we're missing something. > DuplicateServiceException when artifact name equals to alias > ------------------------------------------------------------ > > Key: WFCORE-3429 > URL: https://issues.jboss.org/browse/WFCORE-3429 > Project: WildFly Core > Issue Type: Task > Components: Server > Affects Versions: 2.2.0.Final > Reporter: Сергей Машкевич > Priority: Minor > Labels: support > > Suppose that there is an artifact «moduleA.ear» with the following deployment descriptor: > {code:java} > <?xml version="1.0" encoding="UTF-8"?> > <jboss-deployment-structure> > <deployment> > <module-alias name="deployment.moduleA.ear"/> > </deployment> > </jboss-deployment-structure> > {code} > When I try to deploy this module on *WildFly 10.1.0*, I get the DuplicateServiceException: > {code:java} > jboss.deployment.unit."moduleA.ear".CONFIGURE_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."moduleA.ear".CONFIGURE_MODULE: WFLYSRV0153: Failed to process phase CONFIGURE_MODULE of deployment "moduleA.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.moduleA.ear".main is already registered > at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) > at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) > at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768) > at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) > at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) > at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) > at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) > at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:263) > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:124) > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:87) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) > ... 5 more > {code} > I think this exception should not be thrown in this case. Could you fix it? > Thanks, > Sergey Mashkevich -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3439?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3439: ------------------------------------------ https://ci.wildfly.org/viewLog.html?buildId=81675&tab=buildResultsDiv&bui... is a test of a largely mindless experiment at https://github.com/wildfly/wildfly-core/commit/56dbb15b1f7592b8562316e061.... > Reevaluate MultiphaseOverallContext.transformServerOperation > ------------------------------------------------------------ > > Key: WFCORE-3439 > URL: https://issues.jboss.org/browse/WFCORE-3439 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. > Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. > One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input. > As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2159) DMN Editor: Write example Unit Test for UiModelMappers

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2159?page=com.atlassian.jira.plugi... ] Michael Anstis resolved DROOLS-2159. ------------------------------------ Resolution: Done > DMN Editor: Write example Unit Test for UiModelMappers > ------------------------------------------------------ > > Key: DROOLS-2159 > URL: https://issues.jboss.org/browse/DROOLS-2159 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > Write an example {{UiModelMapper}} Unit Test for [~jomarko] to use as a template. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3396) Provide certificate authority integration

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3396?page=com.atlassian.jira.plugi... ] Farah Juma reassigned WFCORE-3396: ---------------------------------- Assignee: Farah Juma (was: Darran Lofthouse) > Provide certificate authority integration > ----------------------------------------- > > Key: WFCORE-3396 > URL: https://issues.jboss.org/browse/WFCORE-3396 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 4.0.0.Alpha2 > Reporter: Martin Choma > Assignee: Farah Juma > > Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly. > This can simplify administrator work. No need to perform certification renewal routine tasks. > This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate. > [1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-08 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2159) DMN Editor: Write example Unit Test for UiModelMappers

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2159?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2159: ----------------------------------- Description: Write an example {{UiModelMapper}} Unit Test for [~jomarko] to use as a template. (was: Write an example ```UiModelMapper``` Unit Test for [~jomarko] to use as a template.) > DMN Editor: Write example Unit Test for UiModelMappers > ------------------------------------------------------ > > Key: DROOLS-2159 > URL: https://issues.jboss.org/browse/DROOLS-2159 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > Write an example {{UiModelMapper}} Unit Test for [~jomarko] to use as a template. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2159) DMN Editor: Write example Unit Test for UiModelMappers

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-2159: -------------------------------------- Summary: DMN Editor: Write example Unit Test for UiModelMappers Key: DROOLS-2159 URL: https://issues.jboss.org/browse/DROOLS-2159 Project: Drools Issue Type: Enhancement Components: DMN Editor Reporter: Michael Anstis Assignee: Michael Anstis Write an example ```UiModelMapper``` Unit Test for [~jomarko] to use as a template. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2158) DMN Editor: Write example Unit Test for commands

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2158?page=com.atlassian.jira.plugi... ] Michael Anstis resolved DROOLS-2158. ------------------------------------ Resolution: Done > DMN Editor: Write example Unit Test for commands > ------------------------------------------------ > > Key: DROOLS-2158 > URL: https://issues.jboss.org/browse/DROOLS-2158 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > Write some example Unit Tests for commands as a template for [~jomarko] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9587: ---------------------------------------- [~ochaloup] Hi! Just an FYI, long ago I did some experiments related to capabilities and the tx subsystem, mostly trying to work with real use cases in order to work out how the WFCORE stuff should work. I didn't carry on with doing stuff for the tx subsystem because working out what API the capabilities should expose was more than I could take on at the time. And working out that API is really the most important thing. In the tx case it could be a bit complicated. But anyway, FWIW https://github.com/bstansberry/wildfly/commits/use-cap-req has a couple tx-related commits that might have some useful bits and pieces or at least illustrate some things to think about. There are a couple interesting things about tx that I played with. (Note that that code is way way out of date so it should not serve as a reference for how to use capabilities.) The interesting bits were: 1) IIOP can consume a cap from tx in order to set up some corba interceptors. 99% of requirers of capabilities end up consuming an MSC service provided by the capability, but *maybe* this IIOP thing is a use case for the "Custom integration APIs provided by a capability" thing discussed on the "Working with WildFly Capabilities" document. TBH though, AFAIK no other code is using that stuff, while MSC services are really widely used. So if the corba interceptor thing can use a service without too much pain that might be better in the long run. Being the only use case for a bit of tech has it's downsides. ;) 2) IIOP and JTS have a circular relationship, which the capability stuff can support. It's unusual though. 3) Whether JTS is available depends on the setting of an attribute in a resource, rather than the existence of the resource. This is also a bit unusual (but allowed.) A bit of a twist though is unfortunately the 'jts' attribute allows expressions. When a management operation runs, all capabilities and requirements must be recorded in Stage.MODEL. But, if a vault expression is used, the expression cannot be reliably resolved until Stage.RUNTIME. For this reason, we now know to disallow expressions on attributes that control capabilities and requirements. In most cases that's not a problem as we guessed long ago that we shouldn't allow expressions on what we used to call "model reference attributes", e.g. things like "socket-binding=http". But this "jts" one is a different kind of case. We can't break compatibility by no longer allowing expressions for this attribute, but the presence of an expression *might* be a problem. The 3rd commit in that branch has some logic meant to deal with this. It might not be the best approach, but I regarded it as ok at the time. The problem really only exists if someone uses a vault expression for the 'jts' attribute. I regard that as an extreme corner case. So extreme that it's a tiny bit tempting to break compatibility and just fail if we hit it. > Investigate and introduce capabilities for the transactional subsytems transations/xts/rts > ------------------------------------------------------------------------------------------ > > Key: WFLY-9587 > URL: https://issues.jboss.org/browse/WFLY-9587 > Project: WildFly > Issue Type: Feature Request > Components: Transactions, XTS > Affects Versions: 11.0.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. > https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5685) Register management resources for deployment-specific caches

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5685?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5685: --------------------------------- Fix Version/s: (was: 12.0.0.Alpha1) > Register management resources for deployment-specific caches > ------------------------------------------------------------ > > Key: WFLY-5685 > URL: https://issues.jboss.org/browse/WFLY-5685 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 November 2017