[JBoss JIRA] (DROOLS-484) activation-group is ignored after updating a fact
by Shervin Asgari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-484?page=com.atlassian.jira.plugin... ]
Shervin Asgari commented on DROOLS-484:
---------------------------------------
This bug seems to be hitting us.
Can we expect a fix soon?
> activation-group is ignored after updating a fact
> -------------------------------------------------
>
> Key: DROOLS-484
> URL: https://issues.jboss.org/browse/DROOLS-484
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Environment: Windows 7, AMD 64Bit
> Reporter: Holger Rehn
> Assignee: Mark Proctor
>
> - stateful session
> - two rules in one activation-group with different salience (XOR)
> - after inserting one fact, the expected "higher" rule fires
> - after updating that fact, both rules are firing
> Digging into source shows, that org.drools.core.common.DefaultAgenda.fireActivation(...) removes the ActivationGroupNode. After updating the fact, the same instance of Activation has no longer a group node and all rules are firing.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6632) Unable to create replicated cache
by Vinay Lodha (JIRA)
Vinay Lodha created WFLY-6632:
---------------------------------
Summary: Unable to create replicated cache
Key: WFLY-6632
URL: https://issues.jboss.org/browse/WFLY-6632
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 9.0.2.Final
Reporter: Vinay Lodha
Assignee: Paul Ferraro
servers is unable to create replicated or distributed infinispan cache,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1185) Drool Modify operator causing ClassCastException
by gravity Blast! (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1185?page=com.atlassian.jira.plugi... ]
gravity Blast! commented on DROOLS-1185:
----------------------------------------
Exception in thread "main" Exception executing consequence for rule "test-rule" in org.drools.test.arrays_issue.drlRules: java.lang.ClassCastException: org.drools.test.arrays_issue.response cannot be cast to org.drools.core.common.InternalFactHandle
at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1098)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1005)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1348)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1286)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1333)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1324)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1305)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:249)
at org.drools.test.arrays_issue.Main.testRule(Main.java:177)
at org.drools.test.arrays_issue.Main.main(Main.java:60)
Caused by: java.lang.ClassCastException: org.drools.test.arrays_issue.response cannot be cast to org.drools.core.common.InternalFactHandle
at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:398)
at org.drools.test.arrays_issue.drlRules.Rule_test$u45$rule582756648.defaultConsequence(Rule_test$u45$rule582756648.java:10)
at org.drools.test.arrays_issue.drlRules.Rule_test$u45$rule582756648DefaultConsequenceInvoker.evaluate(Unknown Source)
at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1087)
... 11 more
> Drool Modify operator causing ClassCastException
> ------------------------------------------------
>
> Key: DROOLS-1185
> URL: https://issues.jboss.org/browse/DROOLS-1185
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: JBoss BRMS 6.3 on EAP 6.4.6
> Reporter: gravity Blast!
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: modify-issues.zip
>
>
> When using the modify operator in Drools I am getting a java.lang.ClassCastException: org.adcb.finance.ResponseFact cannot be cast to org.drools.core.common.InternalFactHandle.
> This seems to happen in rules that contain Arrays & using the in/not in operator on them. I have other rules using the matches regex expression and I dont get this issue.
> This is a critical issue for us as we're using the RulesExecutionService in 6.4.0 to extend the KIE Execution service and are due to go live very soon so there is no chance of rolling back to 6.3.x without some heavy rework.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1185) Drool Modify operator causing ClassCastException
by gravity Blast! (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1185?page=com.atlassian.jira.plugi... ]
gravity Blast! commented on DROOLS-1185:
----------------------------------------
private static KieContainer kieContainer = null;
public static void main(String[] args) {
testRule();
}
private static synchronized KieContainer getKieContainer() {
if (kieContainer == null) {
KieServices kieServices = KieServices.Factory.get();
kieContainer = kieServices.getKieClasspathContainer();
}
return kieContainer;
}
public static void testRule(){
StatelessKieSession ksession = getKieContainer().getKieBase("drlRules").newStatelessKieSession();
testObject test = new testObject();
List<String> myArrayRes = new ArrayList<String>();
myArrayRes.add("A");
List<String> myArrayRes2 = new ArrayList<String>();
myArrayRes.add("E");
test.setMyArray(myArrayRes);
test.setMyArray2(myArrayRes2);
response resp = new response();
resp.setSuccess(true);
List<GenericCommand<?>> commandList = new ArrayList<GenericCommand<?>>();
commandList.add(new InsertObjectCommand(test));
commandList.add(new InsertObjectCommand(resp));
BatchExecutionCommand batchCommand = new BatchExecutionCommandImpl(commandList);
ksession.execute(batchCommand);
}
> Drool Modify operator causing ClassCastException
> ------------------------------------------------
>
> Key: DROOLS-1185
> URL: https://issues.jboss.org/browse/DROOLS-1185
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: JBoss BRMS 6.3 on EAP 6.4.6
> Reporter: gravity Blast!
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: modify-issues.zip
>
>
> When using the modify operator in Drools I am getting a java.lang.ClassCastException: org.adcb.finance.ResponseFact cannot be cast to org.drools.core.common.InternalFactHandle.
> This seems to happen in rules that contain Arrays & using the in/not in operator on them. I have other rules using the matches regex expression and I dont get this issue.
> This is a critical issue for us as we're using the RulesExecutionService in 6.4.0 to extend the KIE Execution service and are due to go live very soon so there is no chance of rolling back to 6.3.x without some heavy rework.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos commented on WFLY-5332:
-----------------------------------------------
Adding a test case : https://github.com/jboss-set/eap-additional-testsuite/tree/master/modules...
> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5332
> URL: https://issues.jboss.org/browse/WFLY-5332
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new
> thread [up until max-threads]."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
Attachment: JBossThreadPoolReuseIdleThreadsExecutor.jpg
> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5332
> URL: https://issues.jboss.org/browse/WFLY-5332
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new
> thread [up until max-threads]."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
Attachment: (was: JBossThreadPoolReuseIdleThreadsExecutor.jpg)
> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5332
> URL: https://issues.jboss.org/browse/WFLY-5332
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new
> thread [up until max-threads]."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1184) [kie-server-client] JMS configuration username/password overrides JMS connection factory username/password
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1184?page=com.atlassian.jira.plugi... ]
Marek Schmidt updated DROOLS-1184:
----------------------------------
Component/s: kie server
> [kie-server-client] JMS configuration username/password overrides JMS connection factory username/password
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1184
> URL: https://issues.jboss.org/browse/DROOLS-1184
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Reporter: Radek Koubský
> Assignee: Mark Proctor
>
> If a user wants to use custom username/password for JMS client, the JMS client overrides the JMS connection factory username/password when creating a connection to JMS. This results to invalid username/password for a JMS broker.
> Client code using JMS:
> {code:java}
> protected ServiceResponsesList executeJmsCommand( CommandScript command, String classType, String targetCapability, String containerId ) {
> ConnectionFactory factory = config.getConnectionFactory();
> Queue sendQueue = config.getRequestQueue();
> Queue responseQueue = config.getResponseQueue();
> Connection connection = null;
> Session session = null;
> ServiceResponsesList cmdResponse = null;
> String corrId = UUID.randomUUID().toString();
> String selector = "JMSCorrelationID = '" + corrId + "'";
> try {
> // setup
> MessageProducer producer;
> MessageConsumer consumer;
> try {
> if( config.getPassword() != null ) {
> connection = factory.createConnection(config.getUserName(), config.getPassword());
> } else {
> connection = factory.createConnection();
> }
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> producer = session.createProducer(sendQueue);
> consumer = session.createConsumer(responseQueue, selector);
> connection.start();
> } catch( JMSException jmse ) {
> throw new KieServicesException("Unable to setup a JMS connection.", jmse);
> }
> ..........
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1185) Drool Modify operator causing ClassCastException
by gravity Blast! (JIRA)
gravity Blast! created DROOLS-1185:
--------------------------------------
Summary: Drool Modify operator causing ClassCastException
Key: DROOLS-1185
URL: https://issues.jboss.org/browse/DROOLS-1185
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Environment: JBoss BRMS 6.3 on EAP 6.4.6
Reporter: gravity Blast!
Assignee: Mario Fusco
Priority: Blocker
Attachments: modify-issues.zip
When using the modify operator in Drools I am getting a java.lang.ClassCastException: org.adcb.finance.ResponseFact cannot be cast to org.drools.core.common.InternalFactHandle.
This seems to happen in rules that contain Arrays & using the in/not in operator on them. I have other rules using the matches regex expression and I dont get this issue.
This is a critical issue for us as we're using the RulesExecutionService in 6.4.0 to extend the KIE Execution service and are due to go live very soon so there is no chance of rolling back to 6.3.x without some heavy rework.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6626) Add log message indicating disabled <distributable/> flag from web-fragments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6626?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-6626:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1337858
Bugzilla Update: Perform
> Add log message indicating disabled <distributable/> flag from web-fragments
> ----------------------------------------------------------------------------
>
> Key: WFLY-6626
> URL: https://issues.jboss.org/browse/WFLY-6626
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Stuart Douglas
> Attachments: undistributable.war
>
>
> If a web-fragment doesn't have distributable set, then replication is not enabled. This happens silently so it may be confusing to some users that are expecting replication to be enabled when they have set <distributable/> in their WEB-INF/web.xml.
> Other third party libraries they included may have web-fragments without distributable set so it'd be nice to log a notification when this happens so that users are easily informed why replication was not enabled as they may have expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months