Page 1 of 1

Persisting feeder issue

Posted: Tue Oct 30, 2012 10:48 am
by hyunjia
Hi Guys

I have encounter a problem with persisting feeder. Hopefully , you would shed some light for me

I have activated the persisting feature in my server , and it did create a feeder file which shorten the startup time. However, when I change the cube data, e.g. (zeroOut) , then restart the server. All the feeder files were deleted and TM1 will re-generate them again.
If that's the case, does it mean whenever user make changes to the cube, TM1 would rebuild the feeder all over again during restart ? Please correct me if I am wrong.

I am really confused of how the persisting feeder's behavior.

Re: Persisting feeder issue

Posted: Tue Oct 30, 2012 12:00 pm
by qml
The feeder files are updated (not deleted) whenever you run a rule save or a data save - that is if any new feeder flags need to be added, they will be added at that time. When the server is getting up, if it encounters a feeder file, it loads it and skips feeder evaluation; and if there is no feeder file, the evaluation happens as normal and the file gets created.

I'm really not sure why you are experiencing the behaviour you are describing, so you might want to run some more tests and come up with exact description of what happens and when it happens. For example, how do you know feeder files are getting deleted and generated again? How are you able to observe that?

Re: Persisting feeder issue

Posted: Tue Oct 30, 2012 12:53 pm
by lotsaram
You haven't stated which TM1 server version you are using which is absolutely critical for any thing to do with persistent feeders as how this is implemented changed from 9.5.1 to 9.5.2 and again to 10.1.

In principle any time a rule is saved then the <cube>.feeders file will be updated on disk. Likewise if cube data has changed then when a Save Data is performed and the <cube>.cub file is updated then the <cube>.feeders file should also be updated. However sometimes this doesn't happen. If you get a case during server startup where the cub file has a later timestamp than the corresponding feeders file then ALL feeder files will be deleted and all rules evaluated on startup to recreate all feeder files.

Re: Persisting feeder issue

Posted: Wed Nov 07, 2012 2:12 am
by hyunjia
qml wrote:The feeder files are updated (not deleted) whenever you run a rule save or a data save - that is if any new feeder flags need to be added, they will be added at that time. When the server is getting up, if it encounters a feeder file, it loads it and skips feeder evaluation; and if there is no feeder file, the evaluation happens as normal and the file gets created.

I'm really not sure why you are experiencing the behaviour you are describing, so you might want to run some more tests and come up with exact description of what happens and when it happens. For example, how do you know feeder files are getting deleted and generated again? How are you able to observe that?
I have checked those feeder files exist before I restart the server, and they are gone during the restart. TM1 is taking extra long time to caculate and create those feeders file again.

However, I should take a few more test about this , thanks for your insight.

Re: Persisting feeder issue

Posted: Wed Nov 07, 2012 2:13 am
by hyunjia
lotsaram wrote:You haven't stated which TM1 server version you are using which is absolutely critical for any thing to do with persistent feeders as how this is implemented changed from 9.5.1 to 9.5.2 and again to 10.1.

In principle any time a rule is saved then the <cube>.feeders file will be updated on disk. Likewise if cube data has changed then when a Save Data is performed and the <cube>.cub file is updated then the <cube>.feeders file should also be updated. However sometimes this doesn't happen. If you get a case during server startup where the cub file has a later timestamp than the corresponding feeders file then ALL feeder files will be deleted and all rules evaluated on startup to recreate all feeder files.
I am using 9.5.2 , and I would continue to do more testing about this.