Processes Keeps Rolling Back and Re-running

[mce]

Hi,

All dimension update processes started to keep rolling back and run again and again many times. Although it finishes at the end, it causes lots of delay. When we restart TM1 service, the issue disappears. No parallel execution of such processes.
Any ideas why it could be happening?

Regards,

[Christopher Kernahan]

Hi mce,

- what's changed in the process? Can you compare versions?
- are there loops in the process? If so, are these correct?
- can you use ASCIIOUTPUTs to give you information about where the issue might be in the process?

[mce]

there are no changes in the processes and there is no issues with the process. but TM1 server keeps failing to commit and keeps re-rerunning them.

[tomok]

How can you expect anyone to help you if you aren't willing to provide any additional information besides "TM1 server keeps failing to commit and keeps re-rerunning them?" Christopher asked you some very pertinent questions, questions that may not only lead you to the cause, but also provide information about your situation to others on the forum that might help you.

[garry cook]

Might be completely unrelated but worth noting -

Have previously noticed that in 9.1 at least (not tested on other versions), we found a bug that when a chore was running which dealt predominantly with .dim rebuilds and attribute data loads, if a second chore which was scheduled to run began to try to process, it would knock the first chore back to the start again as soon as the first chore tried a savedataall.

So bascially, chore 1 would be set to run processes A, B, C, D & E but then chore 2's scheduler would kick it off when chore 1 had only reached process C. Chore 2 would then kick about and wait until Chore 1 finished before starting however when the savedataall ran in Process D's epilogue, Chore 1 would restart and begin processing again from process A all the way through to E before chore 2 kicked in.Chore 2 would then run through normally. Could make it worse by adding in a Chore 3 as well when we were testing to identify the issue

We put it down to Chore 2 resetting some internal flag that told the server which TI index it had reached. Put through a service request at the time but it came back with upgrade to version x and closed the ticket.

Not clear from your post if you're dealing with a situation like above but may be worth investigating if so.

On the bright side, if memory servers then in earlier versions it used to crash under these situations so could have been worse

[mce]

Might be completely unrelated but worth noting -

Have previously noticed that in 9.1 at least (not tested on other versions), we found a bug that when a chore was running which dealt predominantly with .dim rebuilds and attribute data loads, if a second chore which was scheduled to run began to try to process, it would knock the first chore back to the start again as soon as the first chore tried a savedataall.

So bascially, chore 1 would be set to run processes A, B, C, D & E but then chore 2's scheduler would kick it off when chore 1 had only reached process C. Chore 2 would then kick about and wait until Chore 1 finished before starting however when the savedataall ran in Process D's epilogue, Chore 1 would restart and begin processing again from process A all the way through to E before chore 2 kicked in.Chore 2 would then run through normally. Could make it worse by adding in a Chore 3 as well when we were testing to identify the issue

We put it down to Chore 2 resetting some internal flag that told the server which TI index it had reached. Put through a service request at the time but it came back with upgrade to version x and closed the ticket.

Not clear from your post if you're dealing with a situation like above but may be worth investigating if so.

On the bright side, if memory servers then in earlier versions it used to crash under these situations so could have been worse

Thanks Garry, in our case no chores or processes that update metadata are called before any other process finishes, and we make sure to call SaveDataAll when there is no process running in the server. I have seen similar cases to yours and I would understand if it rolls back in such instances, but in our case it is quite mysterious.

[mce]

How can you expect anyone to help you if you aren't willing to provide any additional information besides "TM1 server keeps failing to commit and keeps re-rerunning them?" Christopher asked you some very pertinent questions, questions that may not only lead you to the cause, but also provide information about your situation to others on the forum that might help you.

Hi Tomok, I am only interested in if anyone has seen similar situations and if so, what was the solution. Regards,