TM1 Forum

I am getting this error
from the tm1server.log file

1664 ERROR 18/12/2008 05:43:59,867 TM1.Rule Stack overflow evaluating feeders. Starting cell: SalesByYear[10000014,115229,Jan,Forecast_Model,2008,Qty]. Feeder: 1222
1664 ERROR 18/12/2008 05:44:04,812 TM1.Rule Stack overflow evaluating feeders. Starting cell: SalesByYear[10000014,115229,Jan,Forecast_Model,2008,MakeandFactoryQty]. Feeder: 2313

AS I have a lot of feeders in this rule/cube it is a bit difficult to debug. However the message is a little better than the one received in 9.1 which was undecipherable.

What I need to know is what does "feeders: 1222" refer to ? I have looked in the rule and line 1222 is not a feeder also line 2313 does not exist. Is there any way a human can find some direction?

I have checked for indexing errors in looking up dim tables ie dimn('Month',!month) +1 or -1 . and am trapping out of range indexes

neilben, i've moved the post because its not a bug, its a design issue with your rules. Stack overflow is usually related to too many IF statements embedded within each other. Can't remember off hand but i think the maximum you can nest is 16, if you post some / all of your code i'm sure someone will be able to spot it.

Overflows can also occur if your feeder chain is too long. E.g. Day 1 feeds to Day 2, which feeds day 3, to day 4 to .... ad infinitum.

This can often occur if you keep track of opening balances. As Steve says, post your code and we can probably point you in the right direction.

Martin

Neil! Didn't realise it was you initially. Welcome to the new forum, make sure Ray jumps on too. How's the summer I'm missing out on?

Just noticed you say you had a lot of feeders so posting your rules probably isn't practical. First I'd have a look in your SalesByYear cube to see what 'Qty' is feeding. I suspect you have a very long chain there, as I think you keep track of all your stock opening balances?

Martin

It also possible that it is not causing an issue with your results and it can be viewed as a warning message.

If Day 1 feeds Day 2 feeds Day3 ..... feeds Day 240 and then the stack breaks
Day 2 will feed Day3 feeds Day4 ..... feeds Day 241 adn then the stack breaks

so if you are getting the results from the system then I wouldn't worry about it.

I do remember a time when if the feeder stack for a cube got blown during a server start then the rest of the feeders for the cube didn't get processed, where as if it got blown during a rule save the rest of the feeders got executed. This was in an early release of 9 I think and it got fixed.

The feeder stack getting blown then does not always cause an issue.

What is often a problem is how many far the rule side looks back, for example if you have some simple rule logic that says

[Today]=[Yesterday];

Then eventually this breaks since when the stack that looks after the nesting of values in this breaks you get an error in the cube. It usually shows up as a circular reference error... TO get round this you tend to stet the rule and enter the value for say the first of Jan every year.

Cheers and Merry Festive Season to all

Thanks for the feedback.

I will investigate all suggestions. Funny that we only encountered this message when we upgraded from tm v8 to tm v9

Just to let you know that it does not seem to impact on our results. just annoying as it it takes extra time for the rule to save as it writes out a large error log.!

We do have to resave the RULE when we reboot TM1 as the rule does not automatically load.

I have placed a check that the index number for a dimnim/dimix lookup is within the correct bounds before doing the lookup.
As we have experienced it trying to go to -1.

I was unaware of the limit to the nested IF's ... We have a very complex set of nested IF's in this Rule so will check it out.

Martin things still going full tilt here I think Ray is on here somewhere, hes away in Napier at moment .

Have a great chrristmas

neilben wrote:Funny that we only encountered this message when we upgraded from tm v8 to tm v9

Yes, I think the feeder stack was significantly reduced. Not sure if that was on purpose or not.

Martin