Hi Jared,
This was really a first attempt at getting something useful to look
inside the chest of a session and extract useful info. Feel free to
look at the classes and propose changes/provide patches. Once it
reaches a state we consider good enough, we can publish it in Drools
API.
Reg
Edson,
I'm using yEd for the graph viewer and tgf as the format for the graph. Here
is the mvel template to produce the tgf file. I left the topten name the
same for now. Did I miss any nodes or edges?
@declare{"topten"}
@code{
buffer = new StringBuilder();
for (ni : session.nodeInfos) {
Jared,
Glad to hear.
Yes, the idea of the API is to extract info from the working
memory and RETE network and expose it to report generation. As you
saw, I am using an MVEL template to generate the report at the moment.
It is very crude, so any suggestions for improvements are most
we
Edson,
Thanks for the report. The top ten on the left was just what I needed to
track down the badly written rules.
The 385 rules generate 823 documents using 2 facts.
My peak heap usage is now only 250mb. Before it would fail with a 1.2GB
heap.
Do you think this report is a good starting
Jared,
Which version of Drools are you using? Drools 5.1 massively
reduces memory consumption for long-running stateful sessions, when
there are lots of update/modify calls, when compared to Drools 5.0.
Also, in 5.1 there is an internal report you can run. I did not
exposed this in dr
Hi,
I'm attempting to track down an out of memory error.
I have ~400 rules that operate on ~1 facts. One set of facts throws an
out of memory error while other sets process w/o an error. It is easy to
reproduce.
When the system runs out of memory there are about 22,000,000 ReteTuple
objects