[JBoss JIRA] (WFCORE-2738) SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy()
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2738?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-2738:
-----------------------------------
Summary: SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy() (was: SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy)
> SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy()
> ----------------------------------------------------------------------
>
> Key: WFCORE-2738
> URL: https://issues.jboss.org/browse/WFCORE-2738
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta17
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> {noformat}
> 19:33:36,944 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "clusterbench-ee7-singleton-jbossall.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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: java.lang.NullPointerException
> at org.jboss.as.server.deployment.module.SubDeploymentDependencyProcessor.deploy(SubDeploymentDependencyProcessor.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2738) SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2738?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-2738:
-----------------------------------
Summary: SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy (was: Attachments.SUB_DEPLOYMENTS leaks on undeploy)
> SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy
> --------------------------------------------------------------------
>
> Key: WFCORE-2738
> URL: https://issues.jboss.org/browse/WFCORE-2738
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta17
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> {noformat}
> 19:33:36,944 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "clusterbench-ee7-singleton-jbossall.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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: java.lang.NullPointerException
> at org.jboss.as.server.deployment.module.SubDeploymentDependencyProcessor.deploy(SubDeploymentDependencyProcessor.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-13:
----------------------------------------
Uses of SimpleOperationDefinitionBuilder.setPrivateEntry(), with a note for each re whether there are any concerns with preventing outside execution:
controller/src/main/java/org/jboss/as/controller/AbstractControllerService.java: INIT_CONTROLLER_OP (ok)
controller/src/main/java/org/jboss/as/controller/CompositeOperationHandler.java: INTERNAL_DEFINITION (ok)
controller/src/main/java/org/jboss/as/controller/operations/common/GenericSubsystemDescribeHandler.java: (consider 'hidden')
controller/src/main/java/org/jboss/as/controller/operations/common/ValidateOperationHandler.java: DEFINITION_PRIVATE (ok)
controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: CheckResourceAccessHandler (ok)
controller/src/main/java/org/jboss/as/controller/registry/ProxyControllerRegistration.java: ProxyStepHandler (ok)
controller/src/main/java/org/jboss/as/controller/transform/SubsystemDescriptionDump.java: (consider 'hidden')
controller/src/test/java/org/jboss/as/controller/notification/NotificationCompositeOperationTestCase.java: (test)
controller/src/test/java/org/jboss/as/controller/notification/OperationWithManyStepsTestCase.java: (test)
controller/src/test/java/org/jboss/as/controller/notification/OperationWithNotificationTestCase.java: (test)
controller/src/test/java/org/jboss/as/controller/test/CastAttributeOperationTestCase.java: (test)
controller/src/test/java/org/jboss/as/controller/test/ReadResourceChildOrderingTestCase.java: (test)
controller/src/test/java/org/jboss/as/controller/test/TestUtils.java: (test)
controller/src/test/java/org/jboss/as/controller/test/WriteAttributeOperationTestCase.java: (test)
domain-management/src/main/java/org/jboss/as/domain/management/access/AccessAuthorizationDomainSlaveConfigHandler.java: (ok)
host-controller/src/main/java/org/jboss/as/domain/controller/operations/ApplyExtensionsHandler.java: (ok)
host-controller/src/main/java/org/jboss/as/domain/controller/operations/GenericModelDescribeOperationHandler.java: (consider 'hidden')
host-controller/src/main/java/org/jboss/as/domain/controller/operations/ReadMasterDomainOperationsHandler.java: (ok)
host-controller/src/main/java/org/jboss/as/domain/controller/resources/ProfileResourceDefinition.java: DESCRIBE (consider 'hidden')
host-controller/src/main/java/org/jboss/as/host/controller/operations/HostModelRegistrationHandler.java: (ok)
host-controller/src/main/java/org/jboss/as/host/controller/operations/InstallationReportHandler.java: (ok)
host-controller/src/main/java/org/jboss/as/host/controller/operations/StartServersHandler.java: (ok)
host-controller/src/main/java/org/jboss/as/host/controller/resources/StoppedServerResource.java: (unused; remove)
server/src/main/java/org/jboss/as/server/DeployerChainAddHandler.java: (ok)
server/src/main/java/org/jboss/as/server/operations/InstallationReportHandler.java: (ok)
server/src/main/java/org/jboss/as/server/operations/ServerDomainProcessReloadHandler.java: (ok)
server/src/main/java/org/jboss/as/server/operations/ServerDomainProcessShutdownHandler.java: (ok)
server/src/main/java/org/jboss/as/server/operations/ServerProcessStateHandler.java: (should be ok but may have to use 'hidden' as this op was documented)
server/src/main/java/org/jboss/as/server/operations/ServerProcessStateHandler.java: (should be ok but may have to use 'hidden' as this op was documented)
server/src/main/java/org/jboss/as/server/operations/ServerResumeHandler.java: DOMAIN_DEFINITION (ok)
server/src/main/java/org/jboss/as/server/operations/ServerSuspendHandler.java: DOMAIN_DEFINITION (ok)
server/src/main/java/org/jboss/as/server/operations/SetServerGroupHostHandler.java: (ok)
subsystem-test/framework/src/main/java/org/jboss/as/subsystem/test/ReadTransformedResourceOperation.java: (test)
By "consider 'hidden'" in the notes above, I mean a new flag on the operation entry that would result in the current behavior of setPrivateEntry -- i.e. the op is not described in the API but will work if invoked. This is basically meant for things that we suspect people may be using and we don't want to break them, but where don't want to commit to the op as part of the published API.
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-13:
----------------------------------------
WFCORE-13 somewhat "blocks" WFCORE-389 because in theory a subsystem that registers a runtime-only op in the domain-wide profile resource tree may want that op executed on servers *only* via the domain, not allowing the user to invoke it on individual servers. The mechanism to do that would be to mark the op as private in the server-level management API.
This is to some extent a purely theoretical situation.
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2719) Better use of the ManagementResourceRegistration data in JMX query handling
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2719:
-------------------------------------
Description:
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.)
Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify on those parts of the tree where a Resource search is necessary.
was:
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.
> Better use of the ManagementResourceRegistration data in JMX query handling
> ---------------------------------------------------------------------------
>
> Key: WFCORE-2719
> URL: https://issues.jboss.org/browse/WFCORE-2719
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
> Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
> No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.)
> Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify on those parts of the tree where a Resource search is necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years