Hi Paul, thank you for your reply!
Our situation happened because we changed a line in a rule, and did not establish cube dependencies (we are relatively new to parallel interaction, and still struggle with how to determine what dependencies are needed in each case) before running a night load in parallel. I think these tasks stuck in "wait" are the threads that establish the dependencies, since in the server logs the last line I can see that was added for this load is the line:
Code: Select all
TM1.Cube.Dependency Adding cube dependency: Cube 'A' depends on cube '}ElementAttributes_B'
We tried cancelling every thread that was running from TM1Top (unfortunately, we don't have OpsConsole), and we succeeded with most, but it is hard to determine which are the ones that establish the dependencies, and which are the ones that load. However, there was one thread that would not cancel, causing all the chores to get stuck in "wait".
Interestingly enough, sometimes (this is the third time we ran into this problem) simply killing the "wait" tasks works, they cancel and then we could restart the processes. In some cases, however, the task would not get cancelled, and we have to do a server reboot. I have not been able to pinpoint what was different in these cases, unfortunately.
I have tried adding AutomaticallyAddCubeDependencies=T to the tm1s.cfg file, but it doesn't seem to work for rule changes, some dependencies are not added. If you have any advise for me on how to avoid this in the future (our current plan of action is: when a rule is changed, run a quick load to and from the cube, to establish cube dependencies before these are ran in parallel), I would be really grateful. Is there some good white paper on how to determine dependencies when changing rules? I have tried googling, but did not find anything really useful. (Sorry if this is offtopic, I have tried asking in a different thread, but didn't manage to get replies)
Thank you in advance, and please excuse me if I left out some critical information!