[JBoss JIRA] Created: (JBRULES-1432) Queries Executed while Rules are Firing Causes Exceptions
by Steve Shabino (JIRA)
Queries Executed while Rules are Firing Causes Exceptions
---------------------------------------------------------
Key: JBRULES-1432
URL: http://jira.jboss.com/jira/browse/JBRULES-1432
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.4
Environment: Sun 1.5.0_04 Windows
Reporter: Steve Shabino
We have a stateful WM into which we periodically (1) insert new facts and fire rules, and (2) execute queries. Drools fails when we allow query execution in another thread during fireAllRules().
Set-up:
- Every 10 seconds, Thread A inserts some facts and calls fireAllRules(). fireAllRules() is never called concurrently with itself.
- Thread B executes many getQueryResults() calls in series (no concurrency in query execution)
Our rule base uses shadow facts for all facts and is set up this way:
conf.setAssertBehaviour(RuleBaseConfiguration.AssertBehaviour.EQUALITY);
conf.setRemoveIdentities(true);
conf.setLogicalOverride(RuleBaseConfiguration.LogicalOverride.DISCARD);
conf.setMaintainTms(true);
conf.setShadowProxy(true);
We are making some use of insertLogical().
Expected:
- Queries are run against the last consistent truth state, even while fireAllRules() is running.
Actual Behavior:
We get this exception:
Caused by: java.lang.RuntimeException: Unable to pop
at org.drools.util.PrimitiveLongStack.pop(PrimitiveLongStack.java:63)
at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:44)
at org.drools.reteoo.ReteooWorkingMemory.getQueryResults(ReteooWorkingMemory.java:90)
This bug occurs under 4.04 and 4.1 Trunk as of 1/22.
Please let us know if we can provide additional information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBRULES-1649) Queryresult.getFactHandles() returns bad handles
by Jaroslaw Kijanowski (JIRA)
Queryresult.getFactHandles() returns bad handles
------------------------------------------------
Key: JBRULES-1649
URL: http://jira.jboss.com/jira/browse/JBRULES-1649
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.7, 5.0.0-M1
Reporter: Jaroslaw Kijanowski
Assigned To: Mark Proctor
This is present in 4.0.7 and trunk (rev. 20565)
I have following code:
TestFact tf1 = new TestFact();
TestFact tf2 = new TestFact();
FactHandle factHandle1 = workingMemory.insert(tf1);
FactHandle factHandle2 = workingMemory.insert(tf2);
workingMemory.fireAllRules();
System.out.println("Expected:");
System.out.println(tf1);
System.out.println(factHandle1);
System.out.println(tf2);
System.out.println(factHandle2);
System.out.println("Received:");
QueryResults queryResults = workingMemory.getQueryResults("getTestFacts");
for ( Iterator it = queryResults.iterator(); it.hasNext(); ) {
QueryResult result = ( QueryResult ) it.next();
System.out.println(result.get(0 ));
System.out.println( result.getFactHandles()[0] );
}
I would expect that result.getFactHandles() returns the same handle I got when I was inserting the fact into the workingmemory
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JGRP-860) GUI to test whether cluster nodes find each other ok
by Bela Ban (JIRA)
GUI to test whether cluster nodes find each other ok
----------------------------------------------------
Key: JGRP-860
URL: https://jira.jboss.org/jira/browse/JGRP-860
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
- New DiscoveryServer (GUI) which listens on a TCP socket at a given port
- Then the nodes are started and connect to the DiscoveryServer via TCP
- Connected nodes are shown in a listbox in the DiscoveryServer's GUI
- The TCP connection between a node and the DS is the *control channel*, and is independent of JGroups (doesn't use a JGroups config)
- The control channel is used to (a) register nodes and (b) send new JGroups configurations from the DS to the nodes
- The GUI has 4 tabs: UDP, TCP dynamic (TCP:MPING config), TCP static (TCP:TCPPING) and External discovery (TCP:TCPGOSSIP).
- Each tab has configuration specific options, e.g. for UDP we have
- multicast address
- multicast port
- TTL
- checkbox: use flush or not
- checkbox: use state transfer or not
- etc etc etc
There are 2 actions buttons: "Discover" and "Save config". The latter saves the current configuration to a file (XML format). The "Discovery" button sends the current config to all nodes, via the control channel. Each node then creates a channel with the received config and connects to the cluster. The DiscoveryServer GUI (which also joins the same cluster) shows all nodes in a second listbox. When the number of nodes in the first and second listbox is the same, then this shows that the config works. In that case, the user can press "Save config" and use the generated config with all cluster nodes.
- In case UDP doesn't work or a user wants a TCP based config from the onset, the user simply clicks on the TCP tab, fills in the required information and clicks on "Discover".
- The initial config for each tab is provided by the corresponding default shipped with JGroups, e.g. UDP uses udp.xml
In a second stage, we could also not just verify that the cluster can be established, but also run some perf tests over it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months