[JBoss JIRA] (WFLY-9122) Containers for distributed work manager tests always started in testsuite/integration/manualmode
by Josef Cacek (JIRA)
Josef Cacek created WFLY-9122:
---------------------------------
Summary: Containers for distributed work manager tests always started in testsuite/integration/manualmode
Key: WFLY-9122
URL: https://issues.jboss.org/browse/WFLY-9122
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Josef Cacek
The Arquillian containers {{dwm-container-0}} and {{dwm-container-1}} are always started in the manualmode testsuite module.
It can lead to port conflicts when another test wants to use its own server configuration with port offset 200 or 300. It also adds additional time to execute single test ({{mvn test -Dtest=MyTestCase}}), because these 2 containers has to be started first.
The {{dwm-*}} containers are used by distributed work manager tests in package {{org.jboss.as.test.manualmode.jca.workmanager.distributed}}.
CC [~rjanik]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1655) Memory leak for session object reference even after disposing it
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1655?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1655:
--------------------------------
Sprint: 2017 Week 28-29
> Memory leak for session object reference even after disposing it
> ----------------------------------------------------------------
>
> Key: DROOLS-1655
> URL: https://issues.jboss.org/browse/DROOLS-1655
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Shailesh T
> Assignee: Mario Fusco
> Priority: Critical
>
> Even after closing session, the objects into it are not getting released. This is critical problem when ruls are run on long running server with intermittent use. With huge
> number of inserted objects it leaks a considerable memory.
> Steps to reproduce:
> 1) Create a stateful session.
> 2) Insert huge number of objects into the session.
> 3) Fire rules.
> 4) Close session with dispose() call provided.
> 5) Run GC process.
> 5) If memory is measured and heap dump is taken it shows that the objects being inserted are still not garbage collected.
> Observations:
> When walked through heap dump it GC root path looks like
> this - value: myPackage.MyObject #1
> <- object - class: org.drools.core.common.DefaultFactHandle, value: myPackage.MyObject #1
> <- value - class: org.drools.core.util.ObjectHashMap$ObjectEntry, value: org.drools.core.common.DefaultFactHandle #29323
> <- [49547] - class: org.drools.core.util.Entry[], value: org.drools.core.util.ObjectHashMap$ObjectEntry #103210
> <- table - class: org.drools.core.util.ObjectHashMap, value: org.drools.core.util.Entry[] #8
> <- equalityMap - class: org.drools.core.common.ClassAwareObjectStore, value: org.drools.core.util.ObjectHashMap #7
> <- objectStore - class: org.drools.core.common.NamedEntryPoint, value: org.drools.core.common.ClassAwareObjectStore #1
> <- defaultEntryPoint - class: org.drools.core.impl.StatefulKnowledgeSessionImpl, value: org.drools.core.common.NamedEntryPoint #1
> <- value - class: java.util.concurrent.ConcurrentHashMap$HashEntry, value: org.drools.core.impl.StatefulKnowledgeSessionImpl #1
> <- [1] - class: java.util.concurrent.ConcurrentHashMap$HashEntry[], value: java.util.concurrent.ConcurrentHashMap$HashEntry #20801
> <- table - class: java.util.concurrent.ConcurrentHashMap$Segment, value: java.util.concurrent.ConcurrentHashMap$HashEntry[] #465
> <- [14] - class: java.util.concurrent.ConcurrentHashMap$Segment[], value: java.util.concurrent.ConcurrentHashMap$Segment #469
> <- segments - class: java.util.concurrent.ConcurrentHashMap, value: java.util.concurrent.ConcurrentHashMap$Segment[] #78
> <- kSessions - class: org.drools.compiler.kie.builder.impl.KieContainerImpl, value: java.util.concurrent.ConcurrentHashMap #78
> <- compiledRB - class: myPackage.RBInfo, value: org.drools.compiler.kie.builder.impl.KieContainerImpl #1
> On further investigations it was found that when new session is create, KieContainerImpl class keeps its reference into 'kSessions' Map. But when session is closed this reference is not released(though such reference is released from KnowledgeBaseImpl).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1655) Memory leak for session object reference even after disposing it
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1655?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1655:
--------------------------------
Issue Type: Bug (was: Feature Request)
> Memory leak for session object reference even after disposing it
> ----------------------------------------------------------------
>
> Key: DROOLS-1655
> URL: https://issues.jboss.org/browse/DROOLS-1655
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Shailesh T
> Assignee: Mario Fusco
> Priority: Critical
>
> Even after closing session, the objects into it are not getting released. This is critical problem when ruls are run on long running server with intermittent use. With huge
> number of inserted objects it leaks a considerable memory.
> Steps to reproduce:
> 1) Create a stateful session.
> 2) Insert huge number of objects into the session.
> 3) Fire rules.
> 4) Close session with dispose() call provided.
> 5) Run GC process.
> 5) If memory is measured and heap dump is taken it shows that the objects being inserted are still not garbage collected.
> Observations:
> When walked through heap dump it GC root path looks like
> this - value: myPackage.MyObject #1
> <- object - class: org.drools.core.common.DefaultFactHandle, value: myPackage.MyObject #1
> <- value - class: org.drools.core.util.ObjectHashMap$ObjectEntry, value: org.drools.core.common.DefaultFactHandle #29323
> <- [49547] - class: org.drools.core.util.Entry[], value: org.drools.core.util.ObjectHashMap$ObjectEntry #103210
> <- table - class: org.drools.core.util.ObjectHashMap, value: org.drools.core.util.Entry[] #8
> <- equalityMap - class: org.drools.core.common.ClassAwareObjectStore, value: org.drools.core.util.ObjectHashMap #7
> <- objectStore - class: org.drools.core.common.NamedEntryPoint, value: org.drools.core.common.ClassAwareObjectStore #1
> <- defaultEntryPoint - class: org.drools.core.impl.StatefulKnowledgeSessionImpl, value: org.drools.core.common.NamedEntryPoint #1
> <- value - class: java.util.concurrent.ConcurrentHashMap$HashEntry, value: org.drools.core.impl.StatefulKnowledgeSessionImpl #1
> <- [1] - class: java.util.concurrent.ConcurrentHashMap$HashEntry[], value: java.util.concurrent.ConcurrentHashMap$HashEntry #20801
> <- table - class: java.util.concurrent.ConcurrentHashMap$Segment, value: java.util.concurrent.ConcurrentHashMap$HashEntry[] #465
> <- [14] - class: java.util.concurrent.ConcurrentHashMap$Segment[], value: java.util.concurrent.ConcurrentHashMap$Segment #469
> <- segments - class: java.util.concurrent.ConcurrentHashMap, value: java.util.concurrent.ConcurrentHashMap$Segment[] #78
> <- kSessions - class: org.drools.compiler.kie.builder.impl.KieContainerImpl, value: java.util.concurrent.ConcurrentHashMap #78
> <- compiledRB - class: myPackage.RBInfo, value: org.drools.compiler.kie.builder.impl.KieContainerImpl #1
> On further investigations it was found that when new session is create, KieContainerImpl class keeps its reference into 'kSessions' Map. But when session is closed this reference is not released(though such reference is released from KnowledgeBaseImpl).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2422) Credential Store alias name in camel case leads to AssertionError.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2422?page=com.atlassian.jira.plugi... ]
Hynek Švábek commented on WFCORE-2422:
--------------------------------------
Hi [~pferraro],
FYI: this issue WFCORE-2406 contains how to enable Assertion for whole Wildfly server.
> Credential Store alias name in camel case leads to AssertionError.
> ------------------------------------------------------------------
>
> Key: WFCORE-2422
> URL: https://issues.jboss.org/browse/WFCORE-2422
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Fix For: 3.0.0.Beta29
>
>
> Credential Store alias name in camel case leads to AssertionError.
> I am not able to reproduce it over jboss-cli but I can reproduce it in tests.
> You can see to attachment.
> *How to reproduce*
> * unzip uppercasealias.zip to wildfly/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/credential/store
> * cd wildfly/testsuite/integration/basic
> * mvn test -Dtest=CredentialStoreTestCase
> In log you can see this:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "testCamelCase"),
> ("alias" => "camelcasenotationalias")
> ]): java.lang.AssertionError
> at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:87)
> at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:99)
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1841)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1739)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1698)
> at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:575)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:270)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.execute(CredentialStoreAliasDefinition.java:209)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1390)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:419)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:240)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9107) Block non-SSL IIOP port when SSL transport is required
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9107?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFLY-9107:
---------------------------------
Description:
When iiop configuration indicates SSL is required client should not be able to connect without SSL.
For example, with
{noformat}
<transport-config confidentiality="required" trust-in-target="supported"/>
{noformat}
connecting to {{monospaced}}corbaloc:iiop:1.2@<url>:3528/JBoss/Naming/root{{monospaced}} should not be possible
> Block non-SSL IIOP port when SSL transport is required
> ------------------------------------------------------
>
> Key: WFLY-9107
> URL: https://issues.jboss.org/browse/WFLY-9107
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
>
> When iiop configuration indicates SSL is required client should not be able to connect without SSL.
> For example, with
> {noformat}
> <transport-config confidentiality="required" trust-in-target="supported"/>
> {noformat}
> connecting to {{monospaced}}corbaloc:iiop:1.2@<url>:3528/JBoss/Naming/root{{monospaced}} should not be possible
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3062) Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3062?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3062:
----------------------------------------
Assignee: Brian Stansberry
I'm going to take this one. The problem here is the AttributeDefinition classes are doing a kind of quadruple duty, defining attributes, operation parameters, operation results and detail fields within all three of the others. But the only case where an access constraint is meaningful is for the top level attribute itself. The RBAC logic is not checking detail fields within ModelType.OBJECT attributes looking for constraints.
Checking those would only be meaningful if we'd do the following:
1) Allow a read of a detail field without allowing a read of the rest of the attribute. I doubt we'd ever entertain this as the way details fields are implemented internally is by an OSH reading the entire attribute and then another OSH in a step just reports the single attribute. Allowing the full read to happen just on some sort of trust that a later step will exclude inaccessible info would be difficult and a likely security hole. This seems like a bit of an edge case as well.
2) Allow reads of the overall attribute so long as the read doesn't violate any constraint. That is, if 'undefined' is not sensitive for the field and the field isn't defined it's ok.
3) Allow writes of the overall attribute so long as the write didn't modify the protected field in an illegal way. That is, if 'undefined' is not sensitive for the field and the write doesn't define the field it's ok. If the sensitive field was defined and the write didn't change the value, that's ok, although allowing that is problematic is a exploit hole as it allows users to 'fish' for values they couldn't otherwise read by submitting writes and seeing what value allows the write to succeed.
Given where we are in the release cycle it's fairly likely that for core 3.0 / WildFly 11 we'd just move the constraint to the top level attribute, possibly with some change to ObjectTypeAttributeDefinition.Builder to make that automatic. The downside to this is we have some attributes that may not have had constraints before that now do. For example, before the http-interface http-update-enabled attribute had no sensitivity constraint, but now it does as it has become a redirect to the new 'http-upgrade' attribute, which will now have a constraint because of the sasl-authentication-factory field.
> Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3062
> URL: https://issues.jboss.org/browse/WFCORE-3062
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta28
> Reporter: Stefan Guilhen
> Assignee: Brian Stansberry
>
> When reading the description of attributes of type OBJECT, the access constraints of the value types contained in the object attribute are not displayed.
> Example: In BaseHttpInterfaceResourceDefinition we have an http-upgrade attribute of type OBJECT that contains the sasl-authentication-factory attribute, which is a simple attribute with an access constraint.
> When running /core-service=management/management-interface=http-interface:read-resource-description(recursive=true) in the CLI the constraint is not displayed for the attribute:
> {noformat}
> "http-upgrade" => {
> "type" => OBJECT,
> "description" => "HTTP Upgrade specific configuration",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "value-type" => {
> "enabled" => {
> "type" => BOOLEAN,
> "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => false
> },
> "sasl-authentication-factory" => {
> "type" => STRING,
> "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2850) AbstractRuntimeOnlyHandler should not add its step on a profile=* resource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2850?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2850:
-------------------------------------
I'm deferring this t o4. I thought I'd updated the places in full that needed updating to account for this, but I must have dreamed that. Looking at all the uses of AbstractRuntimeOnlyHandler in full, too many need update to take it on at this stage of the release cycle and the number of them make me question whether by default disabling the op in a runtime-only server is the right thing to do.
> AbstractRuntimeOnlyHandler should not add its step on a profile=* resource
> ---------------------------------------------------------------------------
>
> Key: WFCORE-2850
> URL: https://issues.jboss.org/browse/WFCORE-2850
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The child resources of /profile=* do not have a runtime behind them, so AbstractRuntimeOnlyStepHandler should not add its Stage.RUNTIME step if the target resources is in that tree.
> This will make it possible to use this class if as part of WFCORE-389 we lift the (currently unenforced) restriction on adding runtime-only ops to profile resources in order to have the DC roll them out to relevant servers. It's particular important in the context of the related WFCORE-2815, which would result in the current AbstractRuntimeOnlyStepHandler impl failing if used on a profile resource, since the step it adds would be rejected.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months