Configuring CloverETL Server to keep more execution history

Howdy,

When I look at the Executions History tab or Tasks History tab in the web portal, I only see history going back 5 days.

Where is this configured? Is it possible to configure CloverETL to maintain history for 2 weeks?

I’m running CloverETL Server 3.4.0.23M1.

Hi,

At CloverETL server you can configure archivator schedule which can archive (or delete) obsolete records from database. This schedule can be created via “Scheduling” tab. Task type of this schedule is “archivator”.

I suppose that exists a schedule of this type on your server. CloverETL server contains by default schedule named “Delete old execution artifacts”.
Please see the details of this job (via button Detail). You can edit settings as you need.

If you need to store execution history for two weeks, please set at least this attributes:

Older than (minutes): 20160
Include executions history: true

Another solution is to create new archivator schedule. Please note, if your server scheduling contains more archivator schedules, please check if deleting of execution history is configured only in one of them.

For more information about tasks and archivator, please see documentation:
http://doc.cloveretl.com/documentation/ … tasks.html

Howdy,

I’ve updated the archivator job per your instructions. I will let you know if that doesn’t work as expected.

Thank you.

After several months of this working fine, it appears that the archivator job somehow got reset to its “factory default” of keeping only 2 hours of execution history. I do not know how this happened.

Is there anything special I need to do to ensure that these settings persist across server restarts and whatnot?

Hi,

Server restart should not be related to your issue as schedules are stored in database. I have also tried to reproduce your issue on my side but Server restart does not change anything in my case. Could you please answer the following questions?

  1. Are you still running CloverETL Server 3.4.0-M1 as stated in your signature? You might want to consider upgrade to a production version instead of milestone.
  2. Has your Server been redeployed since your original question in December?
  3. Which application server and database are you using? (E.g. Tomcat 6.0.35, MySQL 5.5)
  4. How often do you restart your CloverETL Server?
  5. Was the described behavior just one-time issue or the setting resets with every Server restart?
  6. Is the archivator job the only thing reset or all settings are restored to default?
  7. Did you modify the original archivator job or did you create a new one?
  8. Did you modify the default sandbox or the default user somehow?
  9. Are you sure you have the default values? My default value for executions archivator is 1440 minutes = 24 hours instead of your 2 hours.

Thanks in advance.

  1. Yes. Where can I find some upgrade instructions?
  2. What do you mean by redeployed? Like, has the software been installed from scratch on a new server? Nope.
  3. How do I check that? I skimmed the Configuration > CloverETL Info page and couldn’t find mention of either Tomcat or MySQL.
  4. Rarely. A few times a year at most.
  5. Since we don’t restart often, I can’t tell you if this happens with every restart.
  6. I’m not sure. The archivator job was the only one I noticed changed.
  7. I modified the original.
  8. Not that I know of.
  9. Apologies, I have the same default value of 1440. I miscalculated the 2 hours in my original post. :slight_smile:

Thanks for the answers. Here are my comments to some of them:

  1. Here is our upgrade documentation: http://doc.cloveretl.com/documentation/ … erver.html
  2. I mean installed again over the original installation on the same machine. For example due to changed timestamp of change on the clover.war file.
  3. I am sorry, I assumed you had installed it originally and you are aware of the details. But Tomcat+MySQL is enough information for now.
  4. Could you please try to set it again to a different value than default and restart the server again? Is the value changed to default in this case?

To sum it up, please try to reproduce the issue again as mentioned in 5). If the issue persisted, try to upgrade to the latest production release. It is quite a simple process.