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.voi...@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-RightTuple-tp4029988p4029993.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
