[JBoss JIRA] (DROOLS-629) NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs
by Mike Wilson (JIRA)
[ https://issues.jboss.org/browse/DROOLS-629?page=com.atlassian.jira.plugin... ]
Mike Wilson updated DROOLS-629:
-------------------------------
Attachment: drools-gc-causes-npe-example.zip
> NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs
> --------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-629
> URL: https://issues.jboss.org/browse/DROOLS-629
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta3
> Reporter: Mike Wilson
> Assignee: Mark Proctor
> Attachments: drools-gc-causes-npe-example.zip
>
>
> I have observed that the following NullPointerException (NPE) occurs consistently with a very specific set of rules and a very specific set of inputs into a stream session:
> {code}
> java.lang.NullPointerException
> at org.drools.core.util.AbstractHashTable$SingleIndex.equal(AbstractHashTable.java:491)
> at org.drools.core.util.index.LeftTupleList.matches(LeftTupleList.java:266)
> at org.drools.core.util.index.LeftTupleIndexHashTable.get(LeftTupleIndexHashTable.java:434)
> at org.drools.core.util.index.LeftTupleIndexHashTable.getFirst(LeftTupleIndexHashTable.java:217)
> at org.drools.core.reteoo.BetaNode.getFirstLeftTuple(BetaNode.java:443)
> at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:144)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:548)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:229)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:98)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:988)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1274)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1254)
> ...
> {code}
> The exception always occurs on the next call to "insert" and "fireAllRules" after the following method is invoked within the session: org.drools.core.common.DefaultAgenda$DefaultGarbageCollector.forceGcUnlinkedRules().
> I have attached a maven project that contains a JUnit test, which reproduces this exception using Drools version 6.2.0.Beta3.
> A side effect of this exeption occurring in the middle of fireAllRules is that an extra fact is left over in working memory, which is essentially a memory leak. I assume this is because the evaluation of the LHS of the rules is what causes the NPE to occur, so the fact is not deleted, because the RHS of the rules don't execute.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-629) NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs
by Mike Wilson (JIRA)
Mike Wilson created DROOLS-629:
----------------------------------
Summary: NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs
Key: DROOLS-629
URL: https://issues.jboss.org/browse/DROOLS-629
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final, 6.2.0.Beta3
Reporter: Mike Wilson
Assignee: Mark Proctor
I have observed that the following NullPointerException (NPE) occurs consistently with a very specific set of rules and a very specific set of inputs into a stream session:
{code}
java.lang.NullPointerException
at org.drools.core.util.AbstractHashTable$SingleIndex.equal(AbstractHashTable.java:491)
at org.drools.core.util.index.LeftTupleList.matches(LeftTupleList.java:266)
at org.drools.core.util.index.LeftTupleIndexHashTable.get(LeftTupleIndexHashTable.java:434)
at org.drools.core.util.index.LeftTupleIndexHashTable.getFirst(LeftTupleIndexHashTable.java:217)
at org.drools.core.reteoo.BetaNode.getFirstLeftTuple(BetaNode.java:443)
at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:144)
at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:548)
at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:229)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:98)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:988)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1274)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1254)
...
{code}
The exception always occurs on the next call to "insert" and "fireAllRules" after the following method is invoked within the session: org.drools.core.common.DefaultAgenda$DefaultGarbageCollector.forceGcUnlinkedRules().
I have attached a maven project that contains a JUnit test, which reproduces this exception using Drools version 6.2.0.Beta3.
A side effect of this exeption occurring in the middle of fireAllRules is that an extra fact is left over in working memory, which is essentially a memory leak. I assume this is because the evaluation of the LHS of the rules is what causes the NPE to occur, so the fact is not deleted, because the RHS of the rules don't execute.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-786) Improve Memory Performance when Audit Logging is Off
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/SECURITY-786?page=com.atlassian.jira.plug... ]
Philippe Marschall resolved SECURITY-786.
-----------------------------------------
Fix Version/s: PicketBox_4_9_0.Beta1
Resolution: Done
pull request merged
> Improve Memory Performance when Audit Logging is Off
> ----------------------------------------------------
>
> Key: SECURITY-786
> URL: https://issues.jboss.org/browse/SECURITY-786
> Project: PicketBox
> Issue Type: Patch
> Components: JBossSX
> Reporter: Philippe Marschall
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta1
>
>
> We did some profiling of or JBoss AS instance and noticed that audit logging on JavaEE resources is causing most of our allocations outside [TLAB|http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html#TLAB]s. This was a bit surprising to use since we don't have audit logging on. We tracked them down to {{org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(String, Resource, Exception)}} which unnecessarily does an eager string conversion of every {{org.jboss.security.authorization.Resource}}. This could be done lazily on demand when audit logging is on in {{AuditEvent#toString}}. Since the map is already of type {{Map<String,Object>}} simply removing the call to {{#toString()}} fixes this.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-786) Improve Memory Performance when Audit Logging is Off
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/SECURITY-786?page=com.atlassian.jira.plug... ]
Philippe Marschall closed SECURITY-786.
---------------------------------------
> Improve Memory Performance when Audit Logging is Off
> ----------------------------------------------------
>
> Key: SECURITY-786
> URL: https://issues.jboss.org/browse/SECURITY-786
> Project: PicketBox
> Issue Type: Patch
> Components: JBossSX
> Reporter: Philippe Marschall
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta1
>
>
> We did some profiling of or JBoss AS instance and noticed that audit logging on JavaEE resources is causing most of our allocations outside [TLAB|http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html#TLAB]s. This was a bit surprising to use since we don't have audit logging on. We tracked them down to {{org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(String, Resource, Exception)}} which unnecessarily does an eager string conversion of every {{org.jboss.security.authorization.Resource}}. This could be done lazily on demand when audit logging is on in {{AuditEvent#toString}}. Since the map is already of type {{Map<String,Object>}} simply removing the call to {{#toString()}} fixes this.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-787) Speed up SimpleRole#equals
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/SECURITY-787?page=com.atlassian.jira.plug... ]
Philippe Marschall closed SECURITY-787.
---------------------------------------
> Speed up SimpleRole#equals
> --------------------------
>
> Key: SECURITY-787
> URL: https://issues.jboss.org/browse/SECURITY-787
> Project: PicketBox
> Issue Type: Patch
> Components: JBossSX
> Reporter: Philippe Marschall
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta1
>
>
> We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an {{instanceof}} and it always succeeds.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-787) Speed up SimpleRole#equals
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/SECURITY-787?page=com.atlassian.jira.plug... ]
Philippe Marschall resolved SECURITY-787.
-----------------------------------------
Fix Version/s: PicketBox_4_9_0.Beta1
Resolution: Done
Pull Request merged
> Speed up SimpleRole#equals
> --------------------------
>
> Key: SECURITY-787
> URL: https://issues.jboss.org/browse/SECURITY-787
> Project: PicketBox
> Issue Type: Patch
> Components: JBossSX
> Reporter: Philippe Marschall
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta1
>
>
> We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an {{instanceof}} and it always succeeds.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-863) LogAuditProvider allocates too much
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/SECURITY-863?page=com.atlassian.jira.plug... ]
Philippe Marschall closed SECURITY-863.
---------------------------------------
> LogAuditProvider allocates too much
> -----------------------------------
>
> Key: SECURITY-863
> URL: https://issues.jboss.org/browse/SECURITY-863
> Project: PicketBox
> Issue Type: Patch
> Components: JBossSX
> Reporter: Philippe Marschall
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta1
>
>
> {{LogAuditProvider}} always logs the {{AuditEvent}} even if audit logging is disabled. This means the {{AuditEvent}} is always converted to a {{String}} even if the trace log level is disabled. The profiled our application and this causes a lot of allocations outside of TLABs for us even though we have audit logging disabled.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-863) LogAuditProvider allocates too much
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/SECURITY-863?page=com.atlassian.jira.plug... ]
Philippe Marschall resolved SECURITY-863.
-----------------------------------------
Fix Version/s: PicketBox_4_9_0.Beta1
Resolution: Done
pull request merged
> LogAuditProvider allocates too much
> -----------------------------------
>
> Key: SECURITY-863
> URL: https://issues.jboss.org/browse/SECURITY-863
> Project: PicketBox
> Issue Type: Patch
> Components: JBossSX
> Reporter: Philippe Marschall
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta1
>
>
> {{LogAuditProvider}} always logs the {{AuditEvent}} even if audit logging is disabled. This means the {{AuditEvent}} is always converted to a {{String}} even if the trace log level is disabled. The profiled our application and this causes a lot of allocations outside of TLABs for us even though we have audit logging disabled.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years