TM1 Forum

Hello!
I have few processes nested in another TI.
When nested processes have finished main process is still running for a long time (about 1/5 of total process time). And it is not "Commit".
After execution of nested processes there are no actions except for recording statistics in main process.
All this time (between finished nested processes and the main one) in TM1Top "ObjectType" column is displayed "DimensionSubsetMap" and there is no any information in tm1server log.

Has anyone faced a similar problem?

ps: version - IBM Planning Analytics Local 2.0.9.8

Hi,
Does any of your subprocesses update a dimension with heavy hierarchy?
Try to find out which subprocess causes this, by commenting "executeprocess". Then you can find the exact operation, commenting half, half and half of the subprocess's code ("log2 search")

PS This is a drill process, working >1 hour?

Here is a discussion about a process that seems to correlate with the problem you have described.

It may not have anything to do with it, but it was a process that suddenly went to taking way too long to complete and there were no log file entries providing a clue.

Elessar wrote: ↑Tue Jun 08, 2021 9:28 am Hi,
Does any of your subprocesses update a dimension with heavy hierarchy?

Hi, Elessar. Thanks for your recommendations.
Process and sub-processes don't update dimensions at all.

Elessar wrote: ↑Tue Jun 08, 2021 9:28 am Try to find out which subprocess causes this, by commenting "executeprocess". Then you can find the exact operation, commenting half, half and half of the subprocess's code ("log2 search")

Main process has one long-time working subprocess with another subprocess (about 7/10 of total time) with difficult and multi-iterative calculations. If I'll comment this sub-process then of course the problem will gone (I've tried it), but I won't get a results of calculation

Elessar wrote: ↑Tue Jun 08, 2021 9:28 am PS This is a drill process, working >1 hour?

This is not classic drill through command, but the way to start TI process from Architect form

avkaz wrote: ↑Wed Jun 09, 2021 9:28 am but I won't get a results of calculation

Of course, it's not the way to solve the problem. By commenting parts of code, you can figure out what part of code causes the problem, and then try to fix it.

Is B_TECH_Flag_En_0 executed with TM1RunTI from }Drill_RunCalcEntity?
Have you turned on the logger for lock contention?
What code is executing after the calls to B_TECH_Flag_En_0? It is hard to have any idea on this without know exactly what is occurring after those calls in the master process. I know you said just updating statistics, but is a just series of CellPuts or what?

Instead of commenting code out, you could use LogOutput between every line after the B_TECH_Flag_En_0 calls and you could watch the server log to find the offending line(s) of code. That is how I found my issue in the referenced link above.

PavoGa wrote: ↑Wed Jun 09, 2021 1:21 pm Is B_TECH_Flag_En_0 executed with TM1RunTI from }Drill_RunCalcEntity?

PavoGa wrote: ↑Wed Jun 09, 2021 1:21 pm What code is executing after the calls to B_TECH_Flag_En_0? It is hard to have any idea on this without know exactly what is occurring after those calls in the master process. I know you said just updating statistics, but is a just series of CellPuts or what?

It doesn't matter. I commented all of process execution after line with execution long-working sub-process - issue hasn't gone.

PavoGa wrote: ↑Wed Jun 09, 2021 1:21 pm Have you turned on the logger for lock contention?

Do you mean log4j.logger.TM1.Lock=DEBUG parameter?
I tried to do it, but i didn't notice anything unusual there.

PavoGa wrote: ↑Wed Jun 09, 2021 1:21 pm Instead of commenting code out, you could use LogOutput between every line after the B_TECH_Flag_En_0 calls and you could watch the server log to find the offending line(s) of code. That is how I found my issue in the referenced link above.

It is a good idea, thanks.
But as I expected, the time for an unknown action begins after all lines of the main process.
As I said earlier all this time in TM1Top "ObjectType" column is displayed "DimensionSubsetMap". Perhaps it relates to creation of a large number of views and subsets during process (I use temporary views and subsets)?

Well, then here is a long shot: have you re-ordered the dimensions in the affected cubes? I have one cube that was taking an extraordinary amount of time to load and read with TI's and, like in this case, there was no indicator at all. Reordered the dimensions and processing time dropped dramatically to a fraction of the time.

Is the long-running sub-Process executed through ExecuteProcess? Or is it with TM1RunTI using ExecuteCommand with the Wait flag set to 1? If so, might consider switching to using Synchronized and the Wait flag set to 0. That could save the fifteen minutes it sits there at the end possibly.

Just throwing something up against the wall to see if it sticks. If you do isolate the fix, would be great to know what it was. Good luck.

As this is beng executed via a Drill I would check what happens if the TI set is run without being launched from the drill. If it only delays on the drill then I would guess that the Drill is trying to return something to the client, failing in someway and just timing out while it trys to do "something".

Have you changed environments / versions recently, has this ever worked without the large delay?

Is whatever being returned by the drill when intial set-up changed and /or still being skipped over?