[JBoss JIRA] (DROOLS-1576) Intermittently Rule getting executed Twice while using Agenda Groups and Order
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1576?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1576:
-------------------------------------
I gave a quick look at the drls you attached and they look ok for me. I must admit that the terms of the problem are not totally evident for me and however I cannot reproduce it not having your domain model. Please attach to this ticket a test case reproducing the problem with possibly a failing assertion. In this way I'll have a clear idea about where is the misbehaviour of drools that you're claiming and a chance to investigate it without any risk of misunderstandings.
> Intermittently Rule getting executed Twice while using Agenda Groups and Order
> ------------------------------------------------------------------------------
>
> Key: DROOLS-1576
> URL: https://issues.jboss.org/browse/DROOLS-1576
> Project: Drools
> Issue Type: Bug
> Reporter: Siyad Theyparambil Mohammed
> Assignee: Mario Fusco
> Attachments: CreateDedCharges-Rule.txt, CreateFLATFeeCharges-Rule.txt, CreatePSRLCreditCharges-Rule.txt, CreateRPERFeeCharges-Rule.txt, First Execution Result.txt, Second Execution Result.txt
>
>
> Hi,
> We have 4 rules which are divided into 2 agenda groups
> ||Rule||Agenda Group||
> |CreateRPERFeeCharges|createcharges|
> |CreateFLATFeeCharges|createcharges|
> |CreateDedCharges|createcharges|
> |CreatePSRLCreditCharges|postrule|
>
> Focus is set on the agenda group in the following order,
> 1. postrule
> 2. createcharges
> The Rule “CreatePSRLCreditCharges” has named consequences. Based on the accumulated Charge amount we want one of the two consequence to be executed. If you notice the “First Execution Result.txt” this rule was executed twice once for the “IF” and second for “ELSE” but during the second trigger of the rule execution it fired the rule only once with the same data. Could you please look/check and let us know if we have an issue with the rule or is this a bug in drools?
>
> We have attached the all the 4 drls and the results of the 2 execution that was triggered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1386?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1386:
-------------------------------------
I cannot act or "fix" drools in any way without being able to recreate that NPE on my own and investigating it. Since I cannot see that NPE how can I even know if an eventual fix is solving it?
I'm not denying that there could be a issue or bug in drools, I'm just saying that I've no clue on how to reproduce it. Please attach a test case reproducing this NPE and in case you do feel free to reopen this ticket.
Thanks,
Mario
> NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
> --------------------------------------------------------
>
> Key: DROOLS-1386
> URL: https://issues.jboss.org/browse/DROOLS-1386
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final, 7.0.0.Beta4
> Reporter: Arkady Syamtomov
> Assignee: Mario Fusco
> Priority: Critical
>
> In our integration tests which were perfectly running with drools 6.3.0.Final, now we have failures with the following exception during the rules evaluation:
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowRemoved(QueryElementNode.java:444) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftDeletes(PhreakQueryTerminalNode.java:154) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:46) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1364) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1355) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1346) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1195) Coverity, Dereference after null check in KeyStoreCredentialStore (Elytron)
by Martin Choma (JIRA)
Martin Choma created ELY-1195:
---------------------------------
Summary: Coverity, Dereference after null check in KeyStoreCredentialStore (Elytron)
Key: ELY-1195
URL: https://issues.jboss.org/browse/ELY-1195
Project: WildFly Elytron
Issue Type: Bug
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Critical
dataLocation is dereferenced, although it is checked on null before (could be null).
Setting Critical priority as that can cover root cause of real problem with NPE.
{code:java|title=KeyStoreCredentialStore.java}
try {
if (dataLocation != null && Files.exists(dataLocation)) {
char[] password = getStorePassword(protectionParameter);
try (InputStream fileStream = Files.newInputStream(dataLocation)) {
if (useExternalStorage) {
externalStorage.load(fileStream);
} else {
keyStore.load(fileStream, password);
}
}
enumeration = keyStore.aliases();
} else {
keyStore.load(null, null);
enumeration = Collections.emptyEnumeration();
}
} catch (GeneralSecurityException e) {
throw log.cannotInitializeCredentialStore(
log.internalEncryptionProblem(e, dataLocation.toString()));
}
{code}
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=20120...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8828) Creating cluster-connection in CLI must require discovery-group or static-connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-8828?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-8828:
---------------------------------
Description:
cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
{code}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
{
"outcome" => "success",
"result" => {
"allow-direct-connections-only" => false,
"call-failover-timeout" => -1L,
"call-timeout" => 30000L,
"check-period" => 30000L,
"cluster-connection-address" => "jms",
"confirmation-window-size" => 1048576,
"connection-ttl" => 60000L,
"connector-name" => "connector",
"discovery-group" => undefined,
"initial-connect-attempts" => -1,
"max-hops" => 1,
"max-retry-interval" => 2000L,
"message-load-balancing-type" => "ON_DEMAND",
"min-large-message-size" => 102400,
"notification-attempts" => 2,
"notification-interval" => 1000L,
"producer-window-size" => -1,
"reconnect-attempts" => -1,
"retry-interval" => 500L,
"retry-interval-multiplier" => 1.0,
"static-connectors" => undefined,
"use-duplicate-detection" => true
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
Such cluster-connection will not work and is hard to see where is the problem.
All credit for finding this issue goes to [~wwang2016], thanks.
was:
cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
{code}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
{
"outcome" => "success",
"result" => {
"allow-direct-connections-only" => false,
"call-failover-timeout" => -1L,
"call-timeout" => 30000L,
"check-period" => 30000L,
"cluster-connection-address" => "jms",
"confirmation-window-size" => 1048576,
"connection-ttl" => 60000L,
"connector-name" => "connector",
"discovery-group" => undefined,
"initial-connect-attempts" => -1,
"max-hops" => 1,
"max-retry-interval" => 2000L,
"message-load-balancing-type" => "ON_DEMAND",
"min-large-message-size" => 102400,
"notification-attempts" => 2,
"notification-interval" => 1000L,
"producer-window-size" => -1,
"reconnect-attempts" => -1,
"retry-interval" => 500L,
"retry-interval-multiplier" => 1.0,
"static-connectors" => undefined,
"use-duplicate-detection" => true
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
Such cluster-connection will not work and is hard to see where is the problem.
All credit for finding this issue [~wwang2016], thanks.
> Creating cluster-connection in CLI must require discovery-group or static-connector
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8828
> URL: https://issues.jboss.org/browse/WFLY-8828
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
> {
> "outcome" => "success",
> "result" => {
> "allow-direct-connections-only" => false,
> "call-failover-timeout" => -1L,
> "call-timeout" => 30000L,
> "check-period" => 30000L,
> "cluster-connection-address" => "jms",
> "confirmation-window-size" => 1048576,
> "connection-ttl" => 60000L,
> "connector-name" => "connector",
> "discovery-group" => undefined,
> "initial-connect-attempts" => -1,
> "max-hops" => 1,
> "max-retry-interval" => 2000L,
> "message-load-balancing-type" => "ON_DEMAND",
> "min-large-message-size" => 102400,
> "notification-attempts" => 2,
> "notification-interval" => 1000L,
> "producer-window-size" => -1,
> "reconnect-attempts" => -1,
> "retry-interval" => 500L,
> "retry-interval-multiplier" => 1.0,
> "static-connectors" => undefined,
> "use-duplicate-detection" => true
> },
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> Such cluster-connection will not work and is hard to see where is the problem.
> All credit for finding this issue goes to [~wwang2016], thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Petric Coroli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1386?page=com.atlassian.jira.plugi... ]
Petric Coroli commented on DROOLS-1386:
---------------------------------------
[~mfusco] thanks for taking time looking into this. Even though this issue is marked as Resolved with 'can not reproduce' resolution, we do still experience the same NPE behavior. We've run same test against 7.0.0.CR3 and got similar result.
During rule evaluation there is difference in tuples' stagedType values in between 6.3.0 and 6.5.0 (and onwards) releases for the same rule, and that affects the flow of respective TupleSets implementation _addDelete_ method
h6. In 6.3.0
{code:title=LeftTupleSetsImpl.java}
public boolean addDelete(LeftTuple leftTuple) {
switch(leftTuple.getStagedType()) {
case 1:
this.removeInsert(leftTuple);
return this.deleteFirst == null;
case 2:
this.removeUpdate(leftTuple);
default:
leftTuple.setStagedType(3);
if(this.deleteFirst == null) {
this.deleteFirst = leftTuple;
return true;
} else {
leftTuple.setStagedNext(this.deleteFirst);
this.deleteFirst.setStagePrevious(leftTuple);
this.deleteFirst = leftTuple;
return false;
}
}
}
{code}
Staged type value gives us value of 0 here for the rule in question, and thus flow takes us through the _default_ case.
h6. While In 6.5.0 and 7.0.0
{code:title=TupleSetsImpl.java}
public boolean addDelete(T tuple) {
switch(this.getStagedType(tuple)) {
case 1:
this.removeInsert(tuple);
return this.deleteFirst == null;
case 2:
this.removeUpdate(tuple);
default:
this.setStagedType(tuple, 3);
if(this.deleteFirst == null) {
this.deleteFirst = tuple;
return true;
} else {
this.setNextTuple(tuple, this.deleteFirst);
this.setPreviousTuple(this.deleteFirst, tuple);
this.deleteFirst = tuple;
return false;
}
}
}
{code}
Staged type value gives us value of _*2*_ here for the rule in question, and thus flow takes us through the 2nd case, respectively invoking _removeUpdate_ method.
Following the flow inside the _TupleSetsImpl.java.removeUpdate_, we end up in
{code}
else {
next = this.getNextTuple(tuple); // next is null
T previous = this.getPreviousTuple(tuple); // previous is null here
if(next != null) {
this.setPreviousTuple(next, previous);
}
this.setNextTuple(previous, next); // NPE due to previous being null
}
{code}
with _previous_ having null value, hence the NPE down the _setNextTuple_ implementation.
Main differentiator here seems to be the _stagedType_ value that was _0_ in 6.3.0 and it is _2_ now for 6.5.0 and 7.0.0, and this is taking rule evaluation through the removeUpdate method, which, presumably, should not be happening and is not expected, based on the state of the Tuple, i.e. no previous staged tuple available and this is not being asserted within removeUpdate method prior to _setNextTuple_ invocation.
Please let me know if any additional details are required, e.g. drools rule definition, stack trace etc.
This is currently a blocker for us on our way to upgrade the platform to the newer drools releases, and we would really appreciate your help on this one to get understanding whether there is something that we're missing on our end, if there are any migration steps we need to undertake from 6.3.0 to 6.5.0, or if this is a bug similar to DROOLS-1338 . Thank you in advance.
> NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
> --------------------------------------------------------
>
> Key: DROOLS-1386
> URL: https://issues.jboss.org/browse/DROOLS-1386
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final, 7.0.0.Beta4
> Reporter: Arkady Syamtomov
> Assignee: Mario Fusco
> Priority: Critical
>
> In our integration tests which were perfectly running with drools 6.3.0.Final, now we have failures with the following exception during the rules evaluation:
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowRemoved(QueryElementNode.java:444) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftDeletes(PhreakQueryTerminalNode.java:154) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:46) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1364) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1355) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1346) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8828) Creating cluster-connection in CLI must require discovery-group or static-connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-8828?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-8828:
---------------------------------
Forum Reference: https://developer.jboss.org/message/972413
> Creating cluster-connection in CLI must require discovery-group or static-connector
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8828
> URL: https://issues.jboss.org/browse/WFLY-8828
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
> {
> "outcome" => "success",
> "result" => {
> "allow-direct-connections-only" => false,
> "call-failover-timeout" => -1L,
> "call-timeout" => 30000L,
> "check-period" => 30000L,
> "cluster-connection-address" => "jms",
> "confirmation-window-size" => 1048576,
> "connection-ttl" => 60000L,
> "connector-name" => "connector",
> "discovery-group" => undefined,
> "initial-connect-attempts" => -1,
> "max-hops" => 1,
> "max-retry-interval" => 2000L,
> "message-load-balancing-type" => "ON_DEMAND",
> "min-large-message-size" => 102400,
> "notification-attempts" => 2,
> "notification-interval" => 1000L,
> "producer-window-size" => -1,
> "reconnect-attempts" => -1,
> "retry-interval" => 500L,
> "retry-interval-multiplier" => 1.0,
> "static-connectors" => undefined,
> "use-duplicate-detection" => true
> },
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> Such cluster-connection will not work and is hard to see where is the problem.
> All credit for finding this issue [~wwang2016], thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8829) Creating cluster-connection in CLI must require discovery-group or static-connector
by Miroslav Novak (JIRA)
Miroslav Novak created WFLY-8829:
------------------------------------
Summary: Creating cluster-connection in CLI must require discovery-group or static-connector
Key: WFLY-8829
URL: https://issues.jboss.org/browse/WFLY-8829
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Alpha1
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
{code}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
{
"outcome" => "success",
"result" => {
"allow-direct-connections-only" => false,
"call-failover-timeout" => -1L,
"call-timeout" => 30000L,
"check-period" => 30000L,
"cluster-connection-address" => "jms",
"confirmation-window-size" => 1048576,
"connection-ttl" => 60000L,
"connector-name" => "connector",
"discovery-group" => undefined,
"initial-connect-attempts" => -1,
"max-hops" => 1,
"max-retry-interval" => 2000L,
"message-load-balancing-type" => "ON_DEMAND",
"min-large-message-size" => 102400,
"notification-attempts" => 2,
"notification-interval" => 1000L,
"producer-window-size" => -1,
"reconnect-attempts" => -1,
"retry-interval" => 500L,
"retry-interval-multiplier" => 1.0,
"static-connectors" => undefined,
"use-duplicate-detection" => true
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
Such cluster-connection will not work and is hard to see where is the problem.
All credit for finding this issue [~wwang2016], thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8828) Creating cluster-connection in CLI must require discovery-group or static-connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-8828?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-8828:
---------------------------------
Description:
cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
{code}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
{
"outcome" => "success",
"result" => {
"allow-direct-connections-only" => false,
"call-failover-timeout" => -1L,
"call-timeout" => 30000L,
"check-period" => 30000L,
"cluster-connection-address" => "jms",
"confirmation-window-size" => 1048576,
"connection-ttl" => 60000L,
"connector-name" => "connector",
"discovery-group" => undefined,
"initial-connect-attempts" => -1,
"max-hops" => 1,
"max-retry-interval" => 2000L,
"message-load-balancing-type" => "ON_DEMAND",
"min-large-message-size" => 102400,
"notification-attempts" => 2,
"notification-interval" => 1000L,
"producer-window-size" => -1,
"reconnect-attempts" => -1,
"retry-interval" => 500L,
"retry-interval-multiplier" => 1.0,
"static-connectors" => undefined,
"use-duplicate-detection" => true
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
Such cluster-connection will not work and is hard to see where is the problem.
All credit for finding this issue [~wwang2016], thanks.
was:
cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
{code}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
{
"outcome" => "success",
"result" => {
"allow-direct-connections-only" => false,
"call-failover-timeout" => -1L,
"call-timeout" => 30000L,
"check-period" => 30000L,
"cluster-connection-address" => "jms",
"confirmation-window-size" => 1048576,
"connection-ttl" => 60000L,
"connector-name" => "connector",
"discovery-group" => undefined,
"initial-connect-attempts" => -1,
"max-hops" => 1,
"max-retry-interval" => 2000L,
"message-load-balancing-type" => "ON_DEMAND",
"min-large-message-size" => 102400,
"notification-attempts" => 2,
"notification-interval" => 1000L,
"producer-window-size" => -1,
"reconnect-attempts" => -1,
"retry-interval" => 500L,
"retry-interval-multiplier" => 1.0,
"static-connectors" => undefined,
"use-duplicate-detection" => true
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
Such cluster-connection will not work and is hard to see where is the problem.
> Creating cluster-connection in CLI must require discovery-group or static-connector
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8828
> URL: https://issues.jboss.org/browse/WFLY-8828
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
> {
> "outcome" => "success",
> "result" => {
> "allow-direct-connections-only" => false,
> "call-failover-timeout" => -1L,
> "call-timeout" => 30000L,
> "check-period" => 30000L,
> "cluster-connection-address" => "jms",
> "confirmation-window-size" => 1048576,
> "connection-ttl" => 60000L,
> "connector-name" => "connector",
> "discovery-group" => undefined,
> "initial-connect-attempts" => -1,
> "max-hops" => 1,
> "max-retry-interval" => 2000L,
> "message-load-balancing-type" => "ON_DEMAND",
> "min-large-message-size" => 102400,
> "notification-attempts" => 2,
> "notification-interval" => 1000L,
> "producer-window-size" => -1,
> "reconnect-attempts" => -1,
> "retry-interval" => 500L,
> "retry-interval-multiplier" => 1.0,
> "static-connectors" => undefined,
> "use-duplicate-detection" => true
> },
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> Such cluster-connection will not work and is hard to see where is the problem.
> All credit for finding this issue [~wwang2016], thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8828) Creating cluster-connection in CLI must require discovery-group or static-connector
by Miroslav Novak (JIRA)
Miroslav Novak created WFLY-8828:
------------------------------------
Summary: Creating cluster-connection in CLI must require discovery-group or static-connector
Key: WFLY-8828
URL: https://issues.jboss.org/browse/WFLY-8828
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Alpha1
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
cluster-connection must require discovery-group or static-connector (exclusively, not both can be defined) but currently it's possible to create it without it:
{code}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:add(connector-name=connector, cluster-connection-address=jms)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster1:read-resource
{
"outcome" => "success",
"result" => {
"allow-direct-connections-only" => false,
"call-failover-timeout" => -1L,
"call-timeout" => 30000L,
"check-period" => 30000L,
"cluster-connection-address" => "jms",
"confirmation-window-size" => 1048576,
"connection-ttl" => 60000L,
"connector-name" => "connector",
"discovery-group" => undefined,
"initial-connect-attempts" => -1,
"max-hops" => 1,
"max-retry-interval" => 2000L,
"message-load-balancing-type" => "ON_DEMAND",
"min-large-message-size" => 102400,
"notification-attempts" => 2,
"notification-interval" => 1000L,
"producer-window-size" => -1,
"reconnect-attempts" => -1,
"retry-interval" => 500L,
"retry-interval-multiplier" => 1.0,
"static-connectors" => undefined,
"use-duplicate-detection" => true
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
Such cluster-connection will not work and is hard to see where is the problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months