Page 1 of 1

TI Retaining lock on file

Posted: Thu Nov 01, 2018 8:54 am
by Steve Rowe
Hi,
We're having an issue in TM1 11.2.00000.27 (windows server 2016 standard) where occasionally TM1 is retaining a lock on processed file.

In general the file handling routines are working fine, however around 1 in 10k files (say) the TI process is retaining a lock on the file and preventing the archive routines from acting.

File can not be manually delete or moved but can still be read by subsequent TIs.

Not really doing anything different to what we've done at many other sites and with higher volumes of files.

Has anyone encountered this in recent releases?
Any ideas how to release the lock without stopping TM1?

Edit: There is some evidence to indicate that the failure happens when a different set of TIs is running (ODBC feed so no file handling in this). Obviously if this is the trigger I can workaround, just want to see if anyone else has encountered.

Cheers,

Re: TI Retaining lock on file

Posted: Thu Nov 01, 2018 5:54 pm
by lotsaram
Steve Rowe wrote: Thu Nov 01, 2018 8:54 am Has anyone encountered this in recent releases?
Any ideas how to release the lock without stopping TM1?
Yes to 1st question and nope to 2nd.

Do you also notice a lot of sf_file error messages in the tm1server.log, especially on SaveDataAll but also sometimes with TI processes which delete view & subset files ? (which despite the ERROR status don't seem to stop TI processes completing successfully).

Re: TI Retaining lock on file

Posted: Thu Nov 01, 2018 8:57 pm
by ascheevel
We've had the same issue. I've had the server admin unlock the file with varying success, but a model restart always fixes the issue. One thing I tried last summer was to execute a command to delete a file in the prolog tab, wait 20 seconds, and then do a FileExists check. If the file was still there it'd assume the file was locked and exit with ProcessError. I'd then manually point to a new file for the export/import to get through the day until I could restart and re-point to the original. The processes where we've seen this happen the most are when one server calls an export on another via TM1RunTI and then calls an import on the calling server. I originally thought it was a timing issue so I tried having the calling process wait before kicking off the import, but I don't recall that solving the issue; the main culprits were part of our budgeting chores and they've been turned off for a couple months, so I forget. If I were to do the FileExists test after attempted delete again, I would have the exporting file automatically increment to a file that doesn't already exist and then pass the updated file name as parameter to the importing process. I realize this would work only for export/import to TM1 and does nothing to help when anything other than TM1 is dependent on the export file.

Re: TI Retaining lock on file

Posted: Thu Nov 01, 2018 10:23 pm
by paulsimon
Hi

We encountered some similar sounding issues during our upgrade to PA 2.0.5. Because our Server operating system was also old, at the same time we upgraded to Windows Server 2016. We had repeated problems with files being locked. We eventually traced this to an erroneous implementation of User Account Control by our IT guys. It appeared that in certain cases the UAC was taking ownership of the file and overriding any inherited permissions so that only the person who created the file could amend it and even then not always.

The problem is not necessarily related to Windows Server 2016, as the IT guys eventually found and fixed problems in our current Windows Server 2008R2 platforms where we were getting problems in our Prod and Pre-Prod environments though other environments were fine because UAC had been configured differently. However, the problem in Server 2008 was an irritation but on 2016 it was a major blocker to doing anything.

Unfortunately I don't know exactly what was changed. However, it might be worth asking your IT guys to check out UAC policies on your server.

The typical symptoms that we encountered were that the file could be opened in notepad but any attempt to delete, rename, or modify and save back failed.

Regards

Paul Simon