2:50 a.m.
Before I say something, I should know:
* If an EvemetierCalculDHF "accompanies" an EvemetierData object: is
this a 1:1 relationship or are there several EvemetierData objects
tied to a single EvemetierCalculDHF?
* Is EvemetierCalculDHF.evemetier a Collection? (Probably "yes" if the
answer to the first question is "several".
* Why is the (custom) evaluator sumWithNulls used here? One would
think that DIVIDE can be written so as never to return null.
* The extra CE "Object(...) from WRAP_NULL($acc1)" looks contrived. A
constraint on $acc1/sumWithNulls can be written within the accumulate.
* Personally, I abhor grappling with null (UN/WRAP_NULL). One should
think that it is possible to design objects in a way that avoids null
being returned by its getters. (Frequently, it is just a matter of a
little extra effort to think up a reasonable default value and write
the object initialisation accordingly.)
I can say one thing right away:
$obj: EvemetierData() from $evCalcDHF.evemetier
accumulate ( $src: EvemetierData (
pere == $obj.niveau,... )
The first CE picks out *some* EvemetierData object (from a Collection
(?) see Q1). The accumulate collects lots of partially equal
EvemetierData objects. Now, if there is more than one EvemetierData in
that collection, a similar thing will happen, very likely, over and
over again, with the same subset of EvemetierData facts.
If a "representative" is required for matching a set of similar facts
in an accumulate, it is best practice to pick the representative using
a restrictive constraint, e.g., if it has a unique integer id
attribute, pick the one with the smallest id.
-W
On 11/06/2014, bvoisin <benoit.voisin(a)igc-erp.com> wrote:
To help me understand what is happening in the WM, I've just made
a analysis
method (see below), scrutating all the RightTuples from the WM facts and
showing some stats on the 5 biggest ones :
I call it every 100 matchFired and it shows me info like:
Biggest RightTuple types :
- EvemetierData: RightTuple/NotNode[niveau == $niveau, suffixe == $suffixe]
x *209346*
- SuffixeMapDHF: RightTuple/JoinNode[id == $ev.suffixe] x 17610
- EvemetierData: RightTuple/AccumulateNode[this == $obj.father] x 14145
- EvemetierData: RightTuple/AccumulateNode[niveau == $obj.niveau,
affperiode == $obj.affperiode, typeeve_id == $obj.typeeve_id, dteve ==
$obj.dteve, $suffixeMap.toPhaseTOT != null && ( $suffixeMap.toPhaseTOT !=
null && suffixe == $suffixeMap.toPhaseTOT.id )] x 14145
- EvemetierData: RightTuple/NotNode[niveau == $niveau, suffixe == $suffixe,
sources contains $source3] x 11316
I clearly found my suspect N°1. Is there any pre-existing and better written
methods to do this kind of research in drools ?
Regards,
Benoît
Method to be called after each/N match fired or ... It uses Guava for the
collections :
private void analyzeWorkingMemoryTuples()
{
Multiset<String> keys = HashMultiset.create();
for(FactHandle handle:kieSession.getFactHandles())
{
DefaultFactHandle factHandle = (DefaultFactHandle)handle;
String
factType=factHandle.getObject().getClass().getSimpleName();
RightTuple rightTuple = factHandle.getFirstRightTuple();
while(rightTuple!=null)
{
String key = factType + ": RightTuple";
BetaNode sink =
(BetaNode)rightTuple.getRightTupleSink();
if (sink!=null) {
key+= "/" + sink.getClass().getSimpleName();
key+=Arrays.toString(sink.getConstraints());
}
keys.add(key);
rightTuple = rightTuple.getHandleNext();
}
}
ArrayList<Multiset.Entry<String>> entries =
Lists.newArrayList(keys.entrySet());
Collections.sort(entries, new
Comparator<Multiset.Entry<String>>(){
@Override
public int compare(Entry<String> o1, Entry<String> o2)
{
return -Integer.compare(o1.getCount(), o2.getCount());
}
});
String analysis = Joiner.on("\n -
").join(Iterables.limit(entries, 5));
if (!analysis.equals(previousAnalysis))
{
logger.info("Biggest RightTuple types :\n - " + analysis);
previousAnalysis = analysis;
}
}
--
View this message in context:
http://drools.46999.n3.nabble.com/Analysing-OutOfMemory-too-many-RightTup...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users