- This topic has 13 replies, 6 voices, and was last updated 9 years, 10 months ago by
.
-
Topic
-
I am running Cloverleaf version 6.0.2 on Windows 2008 R2 and have a problem sometimes when I stop and start a process: it acts like it does a save cycle. As in it takes all threads and accompanying files (idx, ecd) and renames them to xxx.old.xxx and creates new files. This isn’t ideal since I have an automated process that runs at midnight to do this. When I don’t catch it I can lose history. Anyone else have this happen?
Doesn’t happen all the time, which is what makes it so frustrating.
I use the command
Code:hcienginestop(run) -p processname
. I’ll switch back to right clicking the process in the GUI and see if it happens then also.
-
Replies
-
-
-
Jim,
I don’t believe the .idx, .msg, and .ecd files get switched to .old when you cycle a process…only when you perform a save_cycle from the hcicmd command. When you cycle a process only the .err and .log files get renamed to a .old.
Scott,
We are on 5.8 not 6.0. I’ve never seen that behavior before. Maybe Cloverleaf support can provide some answers for you.
Thanks…
Tom Rioux
-
-
-
Scott,
Does the unexpected “save cycle” happen every time you bounce that process or only some of the time? Does it happen for all processes or just certain ones?
If the action is sporadic, I’m wondering if you have “Automatic SMAT Cycling” turned on for that process; it’s action is based on a file limit you set in the Process config dialog for the SMAT files belonging to that process’s threads.
-
-
Ok, here are responses to the questions:
1. Yes, some contain mixed case.
2. It’s sporadic, how do I see is Auto SMAT cycling is turned on?
3. I have only changed encoding on a couple threads during testing, never on a live thread – and this happens to live threads too.
We upgraded to 6 about 6-7 months ago, and I don’t recall the old system ever having this issue. I am starting to monitor a lot closer when restarting threads/processes to see if I can pin it down. It hasn’t happened in a few weeks, but then again, I haven’t been doing any major configuration lately either.
So – about that Auto SMAT cycling?
-
A screenshots worth a thousand and one words…
This is v6.1, but these setting have been around for many, many, versions.
I have seen in the past that when the process is very busy, the files can grow far beyond the threshold value before getting cycled. Not sure if this still applies in more current versions.
Although I suspect this may not be your problem, it’s something to check just to be sure it’s NOT the problem.
-
-
Scott,
So, you have one less possible cause for your issue. 🙂
My favorite advise and most hated. Enable All EO on your likely process(es) and be prepared to eat up a lot of disk space.
Another thought: If this continues to be a “hard to pin down” problem, then a slight work around might be to change your Site Configuration to include “Enable SMAT History.” This option cause your .old SMAT files to get stored into a SMAT History directory under your exec/processes/ dir structure.
You’ll have to modify your cronjob (or Win2008 Scheduled Task) to work with the modification. However, it should prevent you from losing SMAT data unless you’ve encountered some obscure bug in the software.
-
-
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
