[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
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
1 month, 2 weeks
[JBoss JIRA] Created: (JBRULES-1009) Can't execute rules twice with a second classloader
by aaron dixon (JIRA)
Can't execute rules twice with a second classloader
---------------------------------------------------
Key: JBRULES-1009
URL: http://jira.jboss.com/jira/browse/JBRULES-1009
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.0.MR3
Reporter: aaron dixon
Assigned To: Mark Proctor
Priority: Minor
Attachments: drools-test.zip
I am trying to sequentially perform two rules executions using two
different classloaders in the same VM. I create completely new state
for each execution, yet I still fail on the second execution (the first execution succeeds). I
believe this has to do with some internal static cached state that
JBossRules is maintaining. An integration test is attached as an archived Eclipse project (zip).
Exception thrown:
Exception in thread "main" java.lang.ClassCastException: test.drools.classloader.FooShadowProxy
at org.drools.base.test.drools.classloader.Foo$getName.getValue(Unknown Source)
at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:94)
at org.drools.base.evaluators.StringFactory$StringEqualEvaluator.evaluate(StringFactory.java:85)
at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java:61)
at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java:82)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:121)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:159)
at org.drools.reteoo.Rete.assertObject(Rete.java:175)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584)
at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:63)
at test.drools.classloader.Driver.testRules(Driver.java:49)
at test.drools.classloader.Driver.go(Driver.java:35)
at test.drools.classloader.Driver.main(Driver.java:19)
--
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
13 years
[JBoss JIRA] Created: (JBRULES-1471) Accumulate should not call getResult() more then necessary
by Geoffrey De Smet (JIRA)
Accumulate should not call getResult() more then necessary
----------------------------------------------------------
Key: JBRULES-1471
URL: http://jira.jboss.com/jira/browse/JBRULES-1471
Project: JBoss Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Reteoo
Reporter: Geoffrey De Smet
Assigned To: Edson Tirelli
Fix For: 5.0.0-M1
For this rule:
rule "roomCapacityTooSmall" // TODO it takes 50-90% of the performance of drools-solver
when
$period : Period();
$room : Room($capacity : capacity);
$totalStudentSize : Number(intValue > $capacity) from accumulate(
Exam(period == $period, room == $room, $studentSize : topicStudentSize),
sum($studentSize)
);
...
end
Outside drl, I update 2 out of 700 Exam objects and call fireAllRulesAndCalculateDecisionScore.
The drl never changes an Exam. Period and Room never change.
That results into this log:
Breakpoint reached at org.drools.solver.core.evaluation.EvaluationHandler.fireAllRulesAndCalculateDecisionScore(EvaluationHandler.java:90)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.reverse(SumAccumulateFunction.java:62)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.accumulate(SumAccumulateFunction.java:53)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.reverse(SumAccumulateFunction.java:62)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.accumulate(SumAccumulateFunction.java:53)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.reverse(SumAccumulateFunction.java:62)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.accumulate(SumAccumulateFunction.java:53)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.reverse(SumAccumulateFunction.java:62)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.accumulate(SumAccumulateFunction.java:53)
Breakpoint reached at org.drools.base.accumulators.SumAccumulateFunction.getResult(SumAccumulateFunction.java:70)
There are 4 accumulate calls and 4 reverse calls. That might be accurate.
There are 8 getResult calls, that should only be 1.
Also, the getResult method creates a new Double instance each time:
return new Double( data.total );
It might be better to do
return Double.valueOf(data.total);
to allow the JVM to hot spot optimize it.
--
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
13 years, 1 month
[JBoss JIRA] Created: (JBRULES-946) RuleBase serialization fails with StackOverflowError
by Alexandre Gattiker (JIRA)
RuleBase serialization fails with StackOverflowError
----------------------------------------------------
Key: JBRULES-946
URL: http://jira.jboss.com/jira/browse/JBRULES-946
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.0.MR2
Reporter: Alexandre Gattiker
Assigned To: Mark Proctor
I created 920 rules, all in this format, with different values in the string literals.
rule "Rule_1"
when
$g:Parent()
$c:Child(parent==$g,code=="yyy1")
Item(parentObject==$c,name=="xxx1", value == "1")
Item(parentObject==$c,name=="xxx2",value == "1")
Item(parentObject==$g,name=="xxx3",value == "200")
then
System.out.println("2");
end
With the following code, I create a RuleBase that I serialize.
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
PackageBuilderConfiguration conf = new PackageBuilderConfiguration();
conf.setCompiler(PackageBuilderConfiguration.JANINO);
Reader source = new InputStreamReader(PolicyServiceImpl.class.getResourceAsStream(fileName));
PackageBuilder builder = new PackageBuilder(conf);
builder.addPackageFromDrl(source);
Package pkg = builder.getPackage();
ruleBase.addPackage(pkg);
//serialize RuleBase
File outFile = new File(f.getPath() + ".tmp");
FileOutputStream fout = new FileOutputStream(outFile);
ObjectOutputStream oos = new ObjectOutputStream(fout);
oos.writeObject(ruleBase);
oos.close();
The serialization fails with the following exception. Otherwise the RuleBase is perfectly fine and working.
java.lang.StackOverflowError
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java(Compiled Code))
at java.util.ArrayList.writeObject(ArrayList.java(Compiled Code))
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java(Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Inlined Compiled Code))
at java.util.ArrayList.writeObject(ArrayList.java(Compiled Code))
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java(Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Inlined Compiled Code))
at java.util.ArrayList.writeObject(ArrayList.java(Compiled Code))
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java(Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
(last four lines repeated over 1000 times)
--
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
13 years, 1 month
[JBoss JIRA] Created: (JGRP-364) When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
by Matthew Todd (JIRA)
When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
-------------------------------------------------------------------------------------------------
Key: JGRP-364
URL: http://jira.jboss.com/jira/browse/JGRP-364
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: linux 2.6 kernel x86_64 running java 1.5.0_06
Reporter: Matthew Todd
Assigned To: Bela Ban
I am testing a jgroups tcp_nio configuration using the draw demo.If I start up my 3 nodes one by one then everything works fine. However if I start up node 1, then attempt to start node 2 and 3 in parallel then only node 2 will work. Node 3 will be isolated and not see the other nodes and logs the following message:
org.jgroups.protocols.pbcast.ClientGmsImpl join
WARNING: join(192.158.70.200:7802) sent to 192.158.70.200:7800 timed out, retrying
I am starting the draw demo like this;
java -cp jgroups-all.jar:commons-logging.jar:concurrent.jar:jmxri.jar org.jgroups.demos.Draw -props test.xml
Here is the configuration for one of my nodes:
<config>
<TCP_NIO
bind_addr="192.158.70.200"
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
end_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
/>
<MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8"
bind_addr="192.158.70.200" down_thread="false" up_thread="false"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="true" up_thread="true"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="true" up_thread="true"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<!-- <FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/> -->
<pbcast.STATE_TRANSFER/>
<!-- <pbcast.FLUSH down_thread="false" up_thread="false"/>-->
</config>
Node 2 and 3 have the same configuration except the port they bind to has been changed
--
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
13 years, 4 months