[JBoss JIRA] (DROOLS-368) Memory leak mappedKnowledgeBaseListeners
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-368?page=com.atlassian.jira.plugin... ]
Tibor Zimányi commented on DROOLS-368:
--------------------------------------
Is this still relevant? If not, we should close this.
> Memory leak mappedKnowledgeBaseListeners
> ----------------------------------------
>
> Key: DROOLS-368
> URL: https://issues.jboss.org/browse/DROOLS-368
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Linex
> Reporter: David Tse
> Assignee: Petr Široký
> Priority: Critical
>
> This leak is identified by getting a heap dump. Analysis of the heap dump by Eclipse MAT puts org.drools.retoo.ReteooRuleBase as the prime suspect holding to 47.33% of the 870 MB heap memory with org.drools.retoo.ReteooStatefulSession adding to the problem accounting for an additional 5.25% of the memory leak.
> Examination of the BRMS 5.5.0.Final source code indicates that SFT memory leaks are caused by issues associated with 7 classes in the drools-core module of the community version BRMS 5.5.0.Final. These classes are
> • org.drools.impl.KnowledgeBaseImpl.java
> • org.drools.impl.StatefulKnowledgeSession.java
> • org.drools.retoo.ReteooStatefulSession which extends org.drools.retoo.ReteooWorkingMemory.java which extends org.drools.common.AbstractWorkingMemory.java
> • org.drools.retoo.ReteooRuleBase.java which extends org.drools.common.AbstractRuleBase.java
> The code in the community version has cyclic dependency and these developed into dying pointers.
> 1. org.drools.impl.KnowledgeBaseImpl$KnowledgeBaseEventListenerWrapper is holding a reference to this (KnowledgeBaseImpl)
> 2. KnowledgeBaseImpl is holding a reference to RuleBase (ReteooRuleBase is the implementation class)
> 3. ReteooRuleBase is holding a reference to org.drools.impl.KnowledgeBaseImpl$KnowledgeBaseEventListenerWrapper
> For the second leak, StatefulKnowledgeSessionImpl is holding a reference to ReteooWorkingMemory. ReteooWorkingMemory is also holding a reference to StatefulKnowledgeSessionImpl.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8524) OwnableReentrantLock can't recognize two different but equal transaction objects as the same transaction
by David Lloyd (JIRA)
David Lloyd created WFLY-8524:
---------------------------------
Summary: OwnableReentrantLock can't recognize two different but equal transaction objects as the same transaction
Key: WFLY-8524
URL: https://issues.jboss.org/browse/WFLY-8524
Project: WildFly
Issue Type: Bug
Components: EJB, Transactions
Reporter: David Lloyd
Priority: Critical
The transaction manager is allowed to create more than one Transaction object for an imported transaction, and has been observed to do so in at least distributed JTA cases if not other cases.
The JTA specification says that the equals method must return true for two objects that refer to the same transaction. Therefore OwnableReentrantLock must use equals() on its owner argument.
As an aside, that class should probably also null-check its owner object on lock() to avoid weird states.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1514) Data Object source modify retains validation error
by Steven Waldren (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1514?page=com.atlassian.jira.plugi... ]
Steven Waldren edited comment on DROOLS-1514 at 4/6/17 9:30 AM:
----------------------------------------------------------------
Noticed that when I recreate the data object from scratch (repeat step #7 in my description above) but then add a field in the editor and use "addCode" as the Identifier, the validation error changes to: "Rule Compilation error The field Diagnosis.addCode is not visible"
was (Author: techydoc):
Noticed that when I recreate the data object from scratch (repeat step #7 in my description above) but then add a field in the editor and call is "addCode." The validation error changes to: "Rule Compilation error The field Diagnosis.addCode is not visible"
> Data Object source modify retains validation error
> --------------------------------------------------
>
> Key: DROOLS-1514
> URL: https://issues.jboss.org/browse/DROOLS-1514
> Project: Drools
> Issue Type: Bug
> Components: docker images
> Affects Versions: 6.5.0.Final
> Environment: workbench-showcase docker image
> Reporter: Steven Waldren
> Assignee: Walter Medvedeo
>
> 1. Created new Data Object using editor
> 2. In source view of data object, added method ("addCode") to add item to field that is a List
> 3. Error though during validation.
> 4. Removed added method and saved.
> 5. Validation error remained "Rule Compilation error addCode cannot be resolved or is not a field"
> 6. Deleted data object
> 7. Added fields in editor
> 8. Validation error remained for "addCode" where there is no "addCode" in the entire repository anymore.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1514) Data Object source modify retains validation error
by Steven Waldren (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1514?page=com.atlassian.jira.plugi... ]
Steven Waldren commented on DROOLS-1514:
----------------------------------------
Noticed that when I recreate the data object from scratch (repeat step #7 in my description above) but then add a field in the editor and call is "addCode." The validation error changes to: "Rule Compilation error The field Diagnosis.addCode is not visible"
> Data Object source modify retains validation error
> --------------------------------------------------
>
> Key: DROOLS-1514
> URL: https://issues.jboss.org/browse/DROOLS-1514
> Project: Drools
> Issue Type: Bug
> Components: docker images
> Affects Versions: 6.5.0.Final
> Environment: workbench-showcase docker image
> Reporter: Steven Waldren
> Assignee: Walter Medvedeo
>
> 1. Created new Data Object using editor
> 2. In source view of data object, added method ("addCode") to add item to field that is a List
> 3. Error though during validation.
> 4. Removed added method and saved.
> 5. Validation error remained "Rule Compilation error addCode cannot be resolved or is not a field"
> 6. Deleted data object
> 7. Added fields in editor
> 8. Validation error remained for "addCode" where there is no "addCode" in the entire repository anymore.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-2615:
-------------------------------------
Also: "We see security risk here since attributes allow-sasl-mechanisms and allow-all-mechanisms can cause that user infers that all mechanisms are forbidden as default - based on principle of least privilege."
I happen to agree; in fact, originally, this is how this worked, but it caused failures due in part to the fact that the lack of an allowed set seems to mean all-allowed to some people and none-allowed to other people. Also there's the question of whether such a set implies order like a list or just acceptance like a set/filter. We definitely don't want to force people to have to opt in to individual mechanisms.
Also missing is (for example) any way to exclude mechanisms that use certain crypto primitives like MD4, MD5, or SHA-1 in addition to any way to establish client-side ordering, which would ideally be separate from inclusion criteria. Something like the openssl-style strings for TLS cipher suites, maybe (or maybe that's too big of a hammer for such a small nail).
> Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2615
> URL: https://issues.jboss.org/browse/WFCORE-2615
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: dep.war, wireshark.pcapng
>
>
> In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
> See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
> This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
> We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-2615:
-------------------------------------
* How is the "list of all known mechanisms" created? It is the list of mechanisms provided by server? Or it is hard coded somewhere in client?
It's derived from all the available mechanism implementations that are detected by the providers on that system. When a client performs authentication, it starts with the intersection set between the locally available mechanisms and the list of mechanisms offered by the server.
* We understand that allowing some mechanisms which are not supported by configuration can be useful for standalone clients (e.g. CLI can ask user for password), but is there any scenario when it is useful for authentication-configuration in Elytron subsystem?
It's related to outbound authentication, so theoretically any use case on the CLI is also valid here (consider app client for example). Note that the current behavior is based on one simple criterion: getting the tests to pass.
* Is there any way how to enforce usage of single concrete SASL mechanism?
I think you can only forbid all the other mechanisms right now, meaning you need the full list of them to do it.
* What should be an order of tried SASL mechanism? Is it defined somewhere or is it random? Should SASL mechanisms from allow-sasl-mechanisms have higher priority then other known mechanisms?
The order that clients try SASL mechanisms is currently based on the order that they are presented by the server. There is no mechanism to reorder them.
> Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2615
> URL: https://issues.jboss.org/browse/WFCORE-2615
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: dep.war, wireshark.pcapng
>
>
> In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
> See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
> This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
> We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1506) drools-docs improvements: file structure, dead images, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1506?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1506:
-------------------------------------
Description:
See latest docs here from jenkins:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
- 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
Do a find in single_html output for regex "Knowledge\w".
- Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
- Dead images.
- Dead sections?
- Images in differently named directory than their section adoc.
For example: images in directory GettingInvolved in shared-kie-docs
- Release notes should not reuse images from rest of docs,
because those images get updated over time
and release notes should not change retroactively automatically.
Copy-paste those images in the release notes directories instead of reusing them.
- Every section header needs an anchorId. All existing anchorIds need to be cleaned up. CamelCase to match filenames.
was:
See latest docs here from jenkins:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
- 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
Do a find in single_html output for regex "Knowledge\w".
- Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
- Dead images.
- Dead sections?
- Images in differently named directory than their section adoc.
For example: images in directory GettingInvolved in shared-kie-docs
- Release notes should not reuse images from rest of docs,
because those images get updated over time
and release notes should not change retroactively automatically.
Copy-paste those images in the release notes directories instead of reusing them.
- Every section header needs an anchorId.
> drools-docs improvements: file structure, dead images, etc
> ----------------------------------------------------------
>
> Key: DROOLS-1506
> URL: https://issues.jboss.org/browse/DROOLS-1506
> Project: Drools
> Issue Type: Task
> Components: docs
> Affects Versions: 7.0.0.Beta8
> Reporter: Geoffrey De Smet
>
> See latest docs here from jenkins:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
> - 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
> Do a find in single_html output for regex "Knowledge\w".
> - Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
> - Dead images.
> - Dead sections?
> - Images in differently named directory than their section adoc.
> For example: images in directory GettingInvolved in shared-kie-docs
> - Release notes should not reuse images from rest of docs,
> because those images get updated over time
> and release notes should not change retroactively automatically.
> Copy-paste those images in the release notes directories instead of reusing them.
> - Every section header needs an anchorId. All existing anchorIds need to be cleaned up. CamelCase to match filenames.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1506) drools-docs improvements: file structure, dead images, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1506?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1506:
-------------------------------------
Description:
See latest docs here from jenkins:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
- 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
Do a find in single_html output for regex "Knowledge\w".
- Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
- Dead images.
- Dead sections?
- Images in differently named directory than their section adoc.
For example: images in directory GettingInvolved in shared-kie-docs
- Release notes should not reuse images from rest of docs,
because those images get updated over time
and release notes should not change retroactively automatically.
Copy-paste those images in the release notes directories to reuse them.
- Every section header needs an anchorId.
was:
See latest docs here from jenkins:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
- 4 mentions of KnowledgeSession should be replaced by KieSession. Same for KnowledgeBase, etc.
Do a find in single_html output for regex "Knowledge\w".
- Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
- Dead images.
- Dead sections?
- Images in differently named directory than their section adoc.
For example: images in directory GettingInvolved in shared-kie-docs
- Release notes should not reuse images from rest of docs,
because those images get updated over time
and release notes should not change retroactively automatically.
Copy-paste those images in the release notes directories to reuse them.
- Every section header needs an anchorId.
> drools-docs improvements: file structure, dead images, etc
> ----------------------------------------------------------
>
> Key: DROOLS-1506
> URL: https://issues.jboss.org/browse/DROOLS-1506
> Project: Drools
> Issue Type: Task
> Components: docs
> Affects Versions: 7.0.0.Beta8
> Reporter: Geoffrey De Smet
>
> See latest docs here from jenkins:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
> - 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
> Do a find in single_html output for regex "Knowledge\w".
> - Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
> - Dead images.
> - Dead sections?
> - Images in differently named directory than their section adoc.
> For example: images in directory GettingInvolved in shared-kie-docs
> - Release notes should not reuse images from rest of docs,
> because those images get updated over time
> and release notes should not change retroactively automatically.
> Copy-paste those images in the release notes directories to reuse them.
> - Every section header needs an anchorId.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1506) drools-docs improvements: file structure, dead images, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1506?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1506:
-------------------------------------
Description:
See latest docs here from jenkins:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
- 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
Do a find in single_html output for regex "Knowledge\w".
- Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
- Dead images.
- Dead sections?
- Images in differently named directory than their section adoc.
For example: images in directory GettingInvolved in shared-kie-docs
- Release notes should not reuse images from rest of docs,
because those images get updated over time
and release notes should not change retroactively automatically.
Copy-paste those images in the release notes directories instead of reusing them.
- Every section header needs an anchorId.
was:
See latest docs here from jenkins:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
- 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
Do a find in single_html output for regex "Knowledge\w".
- Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
- Dead images.
- Dead sections?
- Images in differently named directory than their section adoc.
For example: images in directory GettingInvolved in shared-kie-docs
- Release notes should not reuse images from rest of docs,
because those images get updated over time
and release notes should not change retroactively automatically.
Copy-paste those images in the release notes directories to reuse them.
- Every section header needs an anchorId.
> drools-docs improvements: file structure, dead images, etc
> ----------------------------------------------------------
>
> Key: DROOLS-1506
> URL: https://issues.jboss.org/browse/DROOLS-1506
> Project: Drools
> Issue Type: Task
> Components: docs
> Affects Versions: 7.0.0.Beta8
> Reporter: Geoffrey De Smet
>
> See latest docs here from jenkins:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc...
> - 4 mentions of KnowledgeSession (5.x api) should be replaced by KieSession (6 & 7 api). Same for KnowledgeBase, etc.
> Do a find in single_html output for regex "Knowledge\w".
> - Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter
> - Dead images.
> - Dead sections?
> - Images in differently named directory than their section adoc.
> For example: images in directory GettingInvolved in shared-kie-docs
> - Release notes should not reuse images from rest of docs,
> because those images get updated over time
> and release notes should not change retroactively automatically.
> Copy-paste those images in the release notes directories instead of reusing them.
> - Every section header needs an anchorId.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months