Multiple Commit Mode chore - manual Vs scheduled

[failurehappening]

Hello

I have a chore with the following structure:

• Lands some data from Oracle
• Builds the dimensions
• Creates subsets
• Loads Data into cubes
• Extracts data to csv

When this chore is set to Multiple Commit Mode and run manually, i.e. right click run, it completes normally. However, when the process is set to Multiple Commit Mode and scheduled, the chore gets stuck during the 'Extracts data to csv' process on the data tab.

The Extract process creates a view of a 7 dimension summary cube in the prolog, 4 dimensions are top level, period is set as being the top level of one hierarchy, the other 2 dimensions are static subsets (created in the prolog) set at the N level

I put an asciioutput as the last line in the prolog - this gets written out no problem
There is nothing in the metadata tab
I put an asciioutput as the first line in the data tab this does not get written out

According to tm1top the process is looping through a number or rules, this is a summary cube with data being sourced from a number of other cubes. What seems to be happening is that the scheduled chore is having problems accessing / using a view that the same chore run manually has no problem using.

This problem does not occur when I set the chore to Single commit, and run it either scheduled or manually.

Has anyone run into similar issues with scheduling a Multiple Commit Mode chore?

Thanks

TM1 Build Number: 10.1.10000.26473

[Gabor]

I had a similar issue a few months ago, but could not spend time on getting the root cause.
Same TM1 version, running chore manually took about 10 min, scheduled chore ran until next day, so I needed to cancel it.

At that time I have simply tried to alter an existing chore and get benefit of all recent TM1 features, including commit mode, but also other things like direct element insertion. I will try to redo this test in the next couple of days.

[failurehappening]

Hey Gabor

Was your process exporting to flat files by any chance? I was speaking to someone yesterday that mentioned that they had heard that the is an issue with Multiple Commit Mode and flat files... Although they couldn't remember the specifics.

[failurehappening]

IBM Service request raised. I'll update as and when anything interesting comes out of that

[Gabor]

Yes, I was talking about a chore with 8 processes, 2 of them write flat files using ASCIIOUTPUT.

[failurehappening]

IBM has confirmed that this is a bug in the scheduler in 10.1.1, the usual advice applies to resolve... Upgrade

The results for these tests have now come in and it appears that the issue has now been fixed in both 10.2 and 10.2 FP1. We are now able to run your model on multi commit mode via the scheduler.

This issue does not reproduce in 10.2 RP2.

It could be reproduced using 10.1 RP1.

The issue happens in 10.1 RP1 because in multi-commit mode a cache is discarded on one of the 'commits' and then subsequent cell references precipitate a very deep and complex evaluation. This means that it was taking (in 10.1 RP1) about 1 minute to compute the value for one cell. The chore is not "looping" but rather is very busy.

I'm not

[PavoGa]

Ran smackdab into this brickwall last night. It absolutely crushed a chore that was running in 5-6 minutes to the point where after an hour we had to bring the server down.

Thanks for the post.