Server crashing with "Evalution stack overflow"

[Rtel]

Hello

I am getting following error and the server does not start at all.
I have persistent feeder as True

1543 [] INFO 2019-07-29 21:20:22.132 TM1.Server TM1CubeImpl::ProcessFeeders: Computing feeders for base cube 'DATA'.
1543 [] WARN 2019-07-29 21:20:23.295 TM1.Cube Execution aborted - Evaluation Stack Overflow
1543 [] ERROR 2019-07-29 21:20:23.305 TM1.Server Stack overflow evaluating feeders. Starting cell: DATA[2017,0111,Week 15,Final Budget,1111,Trial,AA]. Feeder rule line #: 1
1543 [] WARN 2019-07-29 21:20:23.336 TM1.Cube Execution aborted - Evaluation Stack Overflow

Last 2 lines keeps repeating with different cells in DATA cube and server just hangs.

My thoughts
1) Change the persistent feeders to False and restart the server
2) Is it going to help to comment out entire Rule in Data cube and restart ?..Find the cyclic feeder that is causing the feeders to fire on a long path
3) Can we delete the existing feeder file for DATA cube and on restart it will be recreated ?

Any suggestions please ?

Thanks

Rtel

[Drg]

Hi.

1 yes - you model start longest
2 try clear data in cubes and restart on small data sets
3 yep if you do not touch 1 point

Maybe you have a feeders from leaf level to parent (leaf+1 level) recursion ...???

[Steve Rowe]

Hi,
If you move the rule sheet for the problem cube then your server will start, with PersistentFeeders=F.

This issue normally happens when you feed forward over time, i.e. todays opening balance to tomorrows closing balances.

See this thread for more detail
https://www.tm1forum.com/viewtopic.php?f=3&t=1170

[Rtel]

Hi.

1 yes - you model start longest
2 try clear data in cubes and restart on small data sets
3 yep if you do not touch 1 point

Maybe you have a feeders from leaf level to parent (leaf+1 level) recursion ...???

Thanks for your response, I am trying to break the feeders and will experiment rebooting the server with option 1

[Rtel]

Thanks Steve,

As per your link

['Today']=> DB( Cube,....Attrs('Day', !Day,'Next')....)

can be broken as follows..

#Fails on June 1st
['Jan 1st']=>DB( Cube,....Attrs('Day', !Day,'Next')....)
#Fails on Dec 31st
['Jun 2nd']=>DB( Cube,....Attrs('Day', !Day,'Next')....)


In my case Log files in server points to following line of feeder

['CurrentYear']=>DB('DATA_CUBE',DNEXT('Years',!years),!Weeks,!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');

So can it be broken to following to break to building of stack ?

['2017','CurrentYear']=>DB('DATA_CUBE',DNEXT('Years',!years),!Weeks,!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2018','CurrentYear']=>DB('DATA_CUBE',DNEXT('Years',!years),!Weeks,!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2019','CurrentYear']=>DB('DATA_CUBE',DNEXT('Years',!years),!Weeks,!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2020','CurrentYear']=>DB('DATA_CUBE',DNEXT('Years',!years),!Weeks,!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2021','CurrentYear']=>DB('DATA_CUBE',DNEXT('Years',!years),!Weeks,!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');


Following is another feeder in the Rule that I believe is also breaking the stack since PrevYear of a week feeds PrevYear of next week and this can build a chain of feeder

['PrevYear'] => DB ('DATA_CUBE',!years,DNEXT('weeks',!weeks),!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');

So can it be broken as follows to each year

['2017','PrevYear'] => DB ('DATA_CUBE',!years,DNEXT('weeks',!weeks),!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2018','PrevYear'] => DB ('DATA_CUBE',!years,DNEXT('weeks',!weeks),!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2019','PrevYear'] => DB ('DATA_CUBE',!years,DNEXT('weeks',!weeks),!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2020','PrevYear'] => DB ('DATA_CUBE',!years,DNEXT('weeks',!weeks),!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');
['2021','PrevYear'] => DB ('DATA_CUBE',!years,DNEXT('weeks',!weeks),!DIM1,!DIM2,!DIM3,!DIM4,'PrevYear');


Please let me know if there is a better way to break this 2 feeders mentioned above

Thanks

Rtel

[Wim Gielis]

Hello,

Why is 2017 and 2018 still calculated ? Can't you replace it with values loaded by TI ?

In general (and I did not have a look at Steve's link), you can break the calculation stack by loading values with TI let's say the beginning of the year.
This should be a yearly exercise. And only feed within the year, for example.

Lastly, please use attributes for Next and Previous, rather than relying on functions like DNext and the index order in the dimension.

[Rtel]

Hello,

Why is 2017 and 2018 still calculated ? Can't you replace it with values loaded by TI ?

In general (and I did not have a look at Steve's link), you can break the calculation stack by loading values with TI let's say the beginning of the year.
This should be a yearly exercise. And only feed within the year, for example.

Lastly, please use attributes for Next and Previous, rather than relying on functions like DNext and the index order in the dimension.

Hi Wim, I this case the calendar year for diff client are different, for eg for one client 2019 is current year but for other it may be historical. Thus for a TI to write Previous year data it will have to find historical v/s current year for each client before loading and it may get more complicated with few other business rules.

Do you have any example or some documentation of breaking feeders with TI please ?

I will replace DNext with attributes..Thanks for that

Rtel

[Wim Gielis]

Do you have any example or some documentation of breaking feeders with TI please ?

You should export the cube values (including rules).
Then you disable the rules for, for example, opening balance of a new year.
Finally, you reload the exported data again.

Most of these steps can be automated through Bedrock if you want.

[Steve Rowe]

Hi,

In my experience on the versions where I had models with this issue my approach is as follows. (I'm qualifying this because the behaviour has been different in different releases and I've not had a model like this in recent builds).

I _think_ the stack is 2^9 =512, therefore reset every 500 "steps"
Assumes single daily time dimension for illustrative purposes

#Rule Break points
['Day 500', Opening]=N:[Day 499, Closing];
['Day 1000', Opening]=N:[Day 999, Closing];

#General Rule
[Opening]= N:DB (...........Attrs ('Day' , !Day ,'Prior').....'Closing');


Feeders;

#Feeder break points
[Day 499, Closing]=>[Day 500', Opening];
[Day 999, Closing]=>[Day 1000', Opening];

#General Feeder
[Closing]= N:DB (...........Attrs ('Day' , !Day ,'Next Feeder Safe').....'Opening');

The "Next Feeder Safe" attribute is a special case of the Next attribute where the attribute is not populated on the break point days (i.e. Day 499 and Day 999) this causes the feeder fail and so breaks the prevents the stack overflow.

The same is not required on the rules since (if you get the rule order right) the break points rules prevent the general rule from executing.

As Wim suggests you can avoid this whole issue with a different design by starting each year with an input field, since you a weekly system you won't hit the stack.

[Rtel]

Hello Steve, thanks a lot for sharing this information. I have written below what I have understood from your post.
Kindly let me know if I got it right

-------------------------------------------------------------
#Rule Break points
['Day 500', Opening]=N:[Day 499, Closing];
['Day 1000', Opening]=N:[Day 999, Closing];

#General Rule
[Opening]= N:DB (...........Attrs ('Day' , !Day ,'Prior').....'Closing');


Feeders;

#Feeder break points
[Day 499, Closing]=>[Day 500', Opening];
[Day 999, Closing]=>[Day 1000', Opening];

#General Feeder
[Closing]= N:DB (...........Attrs ('Day' , !Day ,'Next Feeder Safe').....'Opening');
--------------------------------------------------------------------------------------------------------

My understanding ......

As per general feeder all the cells (identified by the right side of the feeder) will be fed (marked to be included in Consolidation) but when a cell identified with Day499 (from left side of feeder) is evaluated ‘Next Feeder safe’ attribute will not have Day500 value in it. Thus the feeder will not be able to identify a cell (on right side of the feeder and thus will break the continuous chain of feeding (ie marking cells from right side of the feeder).
At this moment all the memory stacks will be released.
After this the feeder will continue with next cell ie [‘Day501’, ‘Closing’] and continue marking the cells that needs to be fed until it hits again Day999. At this point feeder cannot identify cell (on right side of feeder) to mark for feeding because again the ‘Next feeder safe’ attribute value for Day999 element is kept empty to break the feeder chain.
At this moment all the memory stacks will be released again.
This process will repeat until all the cell are fed as per the feeder without causing Evaluation stack error
We will have to provide rule and corresponding feeder at each breaking point.

Thanks for your help

Rtel

[Rtel]

Do you have any example or some documentation of breaking feeders with TI please ?

You should export the cube values (including rules).
Then you disable the rules for, for example, opening balance of a new year.
Finally, you reload the exported data again.

Most of these steps can be automated through Bedrock if you want.

Hi Wim, thanks for your feedback. I will explore your suggestions.

Currently I am planning following steps

1) I removed entire Rule from the Cube and restarted the server
2) Run following through a TI.
DebugUtility( 107, 0, 0, 'Cubename', 'Debug.txt', '' );
DebugUtility( 118, 0, 0, ' ', ' ', ' ' );
3) Copy back the Rule and on save command hoping the detailed logging of the rule evaluation.

Hoping this will point to what is causing the trouble. Please let me know if there is anything else.

Thanks

Rtel