I have recently added a cron job to ovosuite to start cleaning up expired trial sites as well as implementing the billing cycle. Under cocoon, its pretty simple to get this done because of the built in Quartz cron block.

<start-cocoon-stuff>

Basically all I did was setup the cron job in cocoon.xconf which points to an internal pipeline that fires off some flow script to handle the logic. To do this you add two entries in cocoon.xconf:

1: The trigger

<trigger name="daily-job" target="org.apache.cocoon.components.cron.CronJob/pipeline-daily"

concurrent-runs="false">
<minutes>1</minutes>
<hours>9</hours>
<days>*</days>
<months>*</months>
<weekdays>?</weekdays>
</trigger>

this defines a trigger (inside //component[@class="org.apache.cocoon.components.cron.CocoonQuartzJobScheduler"]/triggers) that will get the "org.apache.cocoon.components.cron.CronJob/pipeline-daily" and call it daily at 9:01am every day.

2: The Cron Job Component

<component role="org.apache.cocoon.components.cron.CronJob/pipeline-daily"
> logger="cron.pipeline">
<pipeline>ovo/cron/daily</pipeline>
</component>

This defines the component i want called from the above trigger...its the pipeline cron job that will call an internal pipeline defined in the <pipeline> tag.

</end-cocoon-stuff>

I had my flow script building up a basic log email which is sent to me, enabling me to check what the cron job did that day. I had it running over the weekend and when i came in on Monday, i found that i was getting each email twice. A quick look at my flowscript code showed it wasn’t a basic programming error.. and it wasn’t happening on my dev box... hmm was it some wierd threading/linux/scheduling issue?

I was able to reproduce the problem on the linux testing cluster... hmm starting to look like a linux issue...

Another symptom was my cocoon log files were getting truncated and messed up a bit..

I attached a debugger to the linux test cluster (boy i love being able to remote debug) and found that the quartz initialisation code was getting called twice, although the second time it was only breaking in the debugger randomly.... and very rarely at that... luckily i noticed on the second break's stack trace it was loading from the directory scanning as opposed to the server config: breakthrough! The other main difference between my local dev box and the linux servers is the way the deployment is configured. My local runs out of the /cocoon context path, while the linux boxes have the cocoon setup as the default context.

From there it only took a quick google to find i had setup the default context incorrectly by setting the docBase to point to the 'cocoon' directory.. The problem with this is that because the cocoon directory is in the webapps directory, it will get automatically deployed, making cocoon get deployed twice: once as the default app and again as /cocoon.