[JBoss JIRA] (WFLY-6801) EJBClientContext leak: EJBClientContext is not unregistered from TCCLEJBClientContextSelectorService when it's closed
by liang cheng (JIRA)
[ https://issues.jboss.org/browse/WFLY-6801?page=com.atlassian.jira.plugin.... ]
liang cheng updated WFLY-6801:
------------------------------
Steps to Reproduce:
After debugging wildfly source code, I realize the the reproduce steps are very simple. After running following standalone code, you can check the JVM, there are 10 EJBClientContext instances in the heap and could not be GC.
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
public class EJBClientContextLeakTest {
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
Properties props = new Properties();
props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS","JBOSS-LOCAL-USER");
props.put("jboss.naming.client.ejb.context", true);
props.put("org.jboss.ejb.client.scoped.context", true);
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
props.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");
props.put(Context.SECURITY_PRINCIPAL, "myuser");
props.put(Context.SECURITY_CREDENTIALS, "mypassword");
InitialContext context = new InitialContext(props);
context.close();
}
}
}
was:
After debugging wildfly source code, I realize the the reproduce steps are very simple. After running following standalone code, you can check the JVM, there are 10 EJBClientContext instances in the heap and could not be GC.
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
public class EJBClientContextLeakTest {
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
Properties props = new Properties();
props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS","JBOSS-LOCAL-USER");
props.put("jboss.naming.client.ejb.context", true);
props.put("org.jboss.ejb.client.scoped.context", true);
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
props.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");
props.put(Context.SECURITY_PRINCIPAL, "vtbaadmin");
props.put(Context.SECURITY_CREDENTIALS, "vitria");
InitialContext context = new InitialContext(props);
context.close();
}
}
}
> EJBClientContext leak: EJBClientContext is not unregistered from TCCLEJBClientContextSelectorService when it's closed
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6801
> URL: https://issues.jboss.org/browse/WFLY-6801
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final
> Environment: one standalone wildfly on windows7
> Reporter: liang cheng
> Labels: EJBClientContext, naming
> Fix For: 9.x.x TBD
>
>
> After running our code with several days, we found there are many EJbClientContext instances are cached in the heap and could not be GC. And cause the memory leak issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Rodrigo Doria Medina (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1223?page=com.atlassian.jira.plugi... ]
Rodrigo Doria Medina updated DROOLS-1223:
-----------------------------------------
Affects Version/s: 6.4.0.Final
6.3.0.Final
> java.lang.NullPointerException druing Condition Evaluation
> ----------------------------------------------------------
>
> Key: DROOLS-1223
> URL: https://issues.jboss.org/browse/DROOLS-1223
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Rodrigo Doria Medina
> Assignee: Mark Proctor
>
> {panel:title=Code}
> Caused by: java.lang.NullPointerException
> at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
> at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
> at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> {panel}
> This happens when running more than once the same piece of data. (It happens from the second time).
> I have no clue what could that be. When running the first time everything computes as expected.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Rodrigo Doria Medina (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1223?page=com.atlassian.jira.plugi... ]
Rodrigo Doria Medina updated DROOLS-1223:
-----------------------------------------
Description:
{panel:title=Code}
Caused by: java.lang.NullPointerException
at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
{panel}
This happens when running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
was:
# Caused by: java.lang.NullPointerException
# at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
# at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
# at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
# at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
# at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
# at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
# at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
# at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
# at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
# at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
This happens when running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
> java.lang.NullPointerException druing Condition Evaluation
> ----------------------------------------------------------
>
> Key: DROOLS-1223
> URL: https://issues.jboss.org/browse/DROOLS-1223
> Project: Drools
> Issue Type: Bug
> Reporter: Rodrigo Doria Medina
> Assignee: Mark Proctor
>
> {panel:title=Code}
> Caused by: java.lang.NullPointerException
> at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
> at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
> at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> {panel}
> This happens when running more than once the same piece of data. (It happens from the second time).
> I have no clue what could that be. When running the first time everything computes as expected.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Rodrigo Doria Medina (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1223?page=com.atlassian.jira.plugi... ]
Rodrigo Doria Medina updated DROOLS-1223:
-----------------------------------------
Description:
# Caused by: java.lang.NullPointerException
# at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
# at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
# at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
# at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
# at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
# at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
# at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
# at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
# at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
# at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
This happens when running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
was:
All,
I have this issue,
#
# Caused by: java.lang.NullPointerException
# at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
# at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
# at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
# at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
# at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
# at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
# at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
# at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
# at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
# at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
When running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
> java.lang.NullPointerException druing Condition Evaluation
> ----------------------------------------------------------
>
> Key: DROOLS-1223
> URL: https://issues.jboss.org/browse/DROOLS-1223
> Project: Drools
> Issue Type: Bug
> Reporter: Rodrigo Doria Medina
> Assignee: Mark Proctor
>
> # Caused by: java.lang.NullPointerException
> # at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
> # at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> # at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
> # at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
> # at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
> # at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> # at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
> # at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> # at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> # at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> # at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> # at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> This happens when running more than once the same piece of data. (It happens from the second time).
> I have no clue what could that be. When running the first time everything computes as expected.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Rodrigo Doria Medina (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1223?page=com.atlassian.jira.plugi... ]
Rodrigo Doria Medina updated DROOLS-1223:
-----------------------------------------
Description:
All,
I have this issue,
#
# Caused by: java.lang.NullPointerException
# at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
# at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
# at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
# at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
# at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
# at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
# at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
# at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
# at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
# at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
# at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
# at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
# at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
# at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
When running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
was:
All,
I have this issue,
Caused by: java.lang.NullPointerException
at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
When running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
> java.lang.NullPointerException druing Condition Evaluation
> ----------------------------------------------------------
>
> Key: DROOLS-1223
> URL: https://issues.jboss.org/browse/DROOLS-1223
> Project: Drools
> Issue Type: Bug
> Reporter: Rodrigo Doria Medina
> Assignee: Mark Proctor
>
> All,
> I have this issue,
> #
> # Caused by: java.lang.NullPointerException
> # at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
> # at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> # at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
> # at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
> # at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
> # at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
> # at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
> # at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> # at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
> # at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> # at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> # at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> # at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> # at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> # at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> When running more than once the same piece of data. (It happens from the second time).
> I have no clue what could that be. When running the first time everything computes as expected.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (DROOLS-1223) java.lang.NullPointerException druing Condition Evaluation
by Rodrigo Doria Medina (JIRA)
Rodrigo Doria Medina created DROOLS-1223:
--------------------------------------------
Summary: java.lang.NullPointerException druing Condition Evaluation
Key: DROOLS-1223
URL: https://issues.jboss.org/browse/DROOLS-1223
Project: Drools
Issue Type: Bug
Reporter: Rodrigo Doria Medina
Assignee: Mark Proctor
All,
I have this issue,
Caused by: java.lang.NullPointerException
at ConditionEvaluator2afa7f52e3ae42c98bf357b4d12bd2f2.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:146)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:147)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:504)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:434)
at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:359)
at org.drools.core.reteoo.EntryPointNode.propagateModify(EntryPointNode.java:249)
at org.drools.core.phreak.PropagationEntry$Update.execute(PropagationEntry.java:150)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2011)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
When running more than once the same piece of data. (It happens from the second time).
I have no clue what could that be. When running the first time everything computes as expected.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla edited comment on WFLY-6781 at 7/4/16 2:14 PM:
----------------------------------------------------------------
As per your suggestion,
I have tried setting <connection-ttl>60000</connection-ttl> in configuration of RemoteConnectionFactory.
When I do this, even without doing any failover testing , the SL(JMS) is not able to process any request. The status of these request is "processing" for ever.
It might mean that connection has timed out before processing with this setting. Also would like to remind you that the failover by power off method works properly on Linux. Only its got issues (probably JMS related) on Windows OS.
Thanks,
Preeta
was (Author: kpreeta12):
As per your suggestion,
I have tried setting <connection-ttl>60000</connection-ttl> in configuration of RemoteConnectionFactory.
When I do this, even without doing any failover testing , the SL(JMS) is not able to process any request. The status of these request is "processing" for ever.
It might mean that connection has timed out before processing with this setting.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
As per your suggestion,
I have tried setting <connection-ttl>60000</connection-ttl> in configuration of RemoteConnectionFactory.
When I do this, even without doing any failover testing , the SL(JMS) is not able to process any request. The status of these request is "processing" for ever.
It might mean that connection has timed out before processing with this setting.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-6797) Is there a way to have more than one logging subystem belonging to one profile
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6797?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla closed WFLY-6797.
----------------------------------
Resolution: Won't Fix
> Is there a way to have more than one logging subystem belonging to one profile
> ------------------------------------------------------------------------------
>
> Key: WFLY-6797
> URL: https://issues.jboss.org/browse/WFLY-6797
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Brian Stansberry
>
> I have "ha" profile in my domain.xml which has many subsystems.
> Below is the structure I have:-
> {color:#205081}<server-groups>
> <server-group name="main-server-group" profile="ha">
> <socket-binding-group ref="ha-sockets"/>
> <deployments>
> <deployment name="RC.war" runtime-name="RC.war"/>
> </deployments>
> </server-group>
> <server-group name="other-server-group" profile="ha">
> <socket-binding-group ref="standard-sockets"/>
> <deployments>
> <deployment name="SL.war" runtime-name="SL.war"/>
> </deployments>
> </server-group>
> </server-groups>{color}
> There is a logging subsystem which needs to be different for RC.war and SL.war. Both RC.war and SL.war belong to same profile.
>
> Is there a way to have 2 logging related subsystems defined in "ha" profile, such that RC can point to one and SL to the other although they belong to same profile?
> Example:-
> RC.war needs to use the below:-
> {color:#205081}<subsystem xmlns="urn:jboss:domain:logging:2.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> <logger category="com.arjuna">
> <level name="WARN"/>
> </logger>
> <logger category="org.apache.tomcat.util.modeler">
> <level name="WARN"/>
> </logger>
> <logger category="org.jboss.as.config">
> <level name="DEBUG"/>
> </logger>
> <logger category="sun.rmi">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb.config">
> <level name="ERROR"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="CONSOLE"/>
> <handler name="FILE"/>
> </handlers>
> </root-logger>
> <formatter name="PATTERN">
> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> </subsystem>
> {color}
> while SL.war needs to use the below:-
> {color:#205081}<subsystem xmlns="urn:jboss:domain:logging:2.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> <periodic-rotating-file-handler name="ISEE">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="isee.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="FILE_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="fileadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="DB_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="dbadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="MQ_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="mqadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="JMS_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="jmsadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="HTTP_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="httpadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="VMWARE_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="vmwareadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="WSLISTENER_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="wslisteneradapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="SERVICEITEMLISTENER_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="serviceitemlisteneradapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="VSOC_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="vsocadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="CLOUD_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="cloudadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <logger category="com.arjuna">
> <level name="WARN"/>
> </logger>
> <logger category="org.apache.tomcat.util.modeler">
> <level name="WARN"/>
> </logger>
> <logger category="org.jboss.as.config">
> <level name="DEBUG"/>
> </logger>
> <logger category="sun.rmi">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb.config">
> <level name="ERROR"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="CONSOLE"/>
> <handler name="FILE"/>
> </handlers>
> </root-logger>
> <formatter name="PATTERN">
> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> </subsystem>{color}
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0
[JBoss JIRA] (WFLY-6797) Is there a way to have more than one logging subystem belonging to one profile
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6797?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6797:
----------------------------------------
I have fixed the issue by creating 2 different profiles.
I read about logging-profiles and per-deployment logging. However these didn't work for me. Hence created 2 different profiles. Each profile had many similar subsystems.
> Is there a way to have more than one logging subystem belonging to one profile
> ------------------------------------------------------------------------------
>
> Key: WFLY-6797
> URL: https://issues.jboss.org/browse/WFLY-6797
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Brian Stansberry
>
> I have "ha" profile in my domain.xml which has many subsystems.
> Below is the structure I have:-
> {color:#205081}<server-groups>
> <server-group name="main-server-group" profile="ha">
> <socket-binding-group ref="ha-sockets"/>
> <deployments>
> <deployment name="RC.war" runtime-name="RC.war"/>
> </deployments>
> </server-group>
> <server-group name="other-server-group" profile="ha">
> <socket-binding-group ref="standard-sockets"/>
> <deployments>
> <deployment name="SL.war" runtime-name="SL.war"/>
> </deployments>
> </server-group>
> </server-groups>{color}
> There is a logging subsystem which needs to be different for RC.war and SL.war. Both RC.war and SL.war belong to same profile.
>
> Is there a way to have 2 logging related subsystems defined in "ha" profile, such that RC can point to one and SL to the other although they belong to same profile?
> Example:-
> RC.war needs to use the below:-
> {color:#205081}<subsystem xmlns="urn:jboss:domain:logging:2.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> <logger category="com.arjuna">
> <level name="WARN"/>
> </logger>
> <logger category="org.apache.tomcat.util.modeler">
> <level name="WARN"/>
> </logger>
> <logger category="org.jboss.as.config">
> <level name="DEBUG"/>
> </logger>
> <logger category="sun.rmi">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb.config">
> <level name="ERROR"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="CONSOLE"/>
> <handler name="FILE"/>
> </handlers>
> </root-logger>
> <formatter name="PATTERN">
> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> </subsystem>
> {color}
> while SL.war needs to use the below:-
> {color:#205081}<subsystem xmlns="urn:jboss:domain:logging:2.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> <periodic-rotating-file-handler name="ISEE">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="isee.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="FILE_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="fileadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="DB_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="dbadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="MQ_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="mqadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="JMS_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="jmsadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="HTTP_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="httpadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="VMWARE_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="vmwareadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="WSLISTENER_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="wslisteneradapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="SERVICEITEMLISTENER_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="serviceitemlisteneradapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="VSOC_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="vsocadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <periodic-rotating-file-handler name="CLOUD_ADAPTER">
> <formatter>
> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="cloudadapter.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="false"/>
> </periodic-rotating-file-handler>
> <logger category="com.arjuna">
> <level name="WARN"/>
> </logger>
> <logger category="org.apache.tomcat.util.modeler">
> <level name="WARN"/>
> </logger>
> <logger category="org.jboss.as.config">
> <level name="DEBUG"/>
> </logger>
> <logger category="sun.rmi">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb.config">
> <level name="ERROR"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="CONSOLE"/>
> <handler name="FILE"/>
> </handlers>
> </root-logger>
> <formatter name="PATTERN">
> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> </subsystem>{color}
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
- 1
- 0