Executing startup chore blocks visibility of server

[David Usherwood]

Client of ours has 10.2 and set a heavy freeze job to run on server startup. It's running fine, but the server isn't visible to users, or to TM1Top. Is this what other forumers have found to happen?

[declanr]

Only seen behaviour like that when using Bulk Load Mode but I've not really ran any extensive chores on start up yet.

You mention TM1Top can't see it, what does the ops console say? Does it get stuck on the "Server is Starting" message or do something else?

[David Usherwood]

We aren't running Ops Console. (I was seriously put off by the painful install of the first version and still see lots of issues posted here about later releases.)
Looking at earlier logs the 'TM1 Server is Ready' message appears after the chore is completed.

[lotsaram]

Client of ours has 10.2 and set a heavy freeze job to run on server startup. It's running fine, but the server isn't visible to users, or to TM1Top. Is this what other forumers have found to happen?

The server is only up and available for users to log in after startup chores have completed.

If you want to run a job that is long running best to avoid having it in startup chores (e.g. something with lots of view constructs).

[rmackenzie]

I encountered issues running TIs that address security and attributes so I'm assuming there are things to be aware of, or limitations, around sensible things that can be performed with start-up chores. Nothing I was running lasted long enough for there to be notable issues around server availability though.

[paulsimon]

Hi David

I can confirm that the TM1 Server does not appear to be registered until the StartUp Chore has finished. Therefore it won't show up in TM1 Top or if you do Refresh Available Servers in the Client.

In some ways this can be useful. For example, we were loading from a database. Each batch of updates had a sequential number. We knew that when loading we only had to load data for batches higher than the last number loaded. This was held in a cube. We ensured that, when the number was stored in the cube, that logging was turned off, so that it would be lost in the event of a crash, as would the data that had been loaded. We then set up a StartUpChore to run this process, so that, if the server crashed, it would automatically recover from the source data. The only other alternative would have been to leave logging turned on during loading which was generating huge log files and adding an overhead to the loads, which was a big hit to take for relatively rare crashes.

Regards

Paul Simon