cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Larsen" <gary.lar...@envisn.com>
Subject Cron job not releasing memory
Date Fri, 13 Jan 2006 13:11:58 GMT
I posted this in the user list without any feedback so I'm trying here.  I'm
running a periodic background process to maintain data in eXist.
 
I'm using Cocoon 2.1.7 and have set up a schedule to run every minute by
setting up a trigger in cocoon.xconf:

 <trigger name="com.envisn.nv.config.ConfigurationManager"
 
target="com.envisn.nv.config.ConfigurationManager"concurrent-runs="false">
  <cron>0 0/1 * * * ? *</cron> <!-- every minute --> 
</trigger>
 
The trigger executes a class that manages the scheduling of a job, and if it
needs to, it adds a new entry:
 
  JobScheduler scheduler =
(JobScheduler)this.manager.lookup(JobScheduler.ROLE);
  SynchronizerDaemon daemon = createSynchronizerDaemon(context);
  scheduler.addPeriodicJob(SynchronizerDaemon.class.getName(), daemon,
minutes, false, null, null);
 
The job runs on schedule perfectly but there appears to a problem with the
job execution releasing resources. Each run of the job adds to the memory
consumption and eventually will create an out of memory error.
 
I tried to track down the memory leak with JProfiler. I had the app run the
job only once.  After execution the resources that were created when the job
started still exist. Here are a few lines from the allocation call tree that
was created from the job which show that PooledExecutor$Worker.run is not
being released:
 
80.6% - 44,761 kB - 661,134 alloc. 
   EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run
80.5% - 44,738 kB - 660,138 alloc. 
    org.quartz.core.JobRunShell.run
79.9% - 44,375 kB - 654,219 alloc.
     com.envisn.nv.sync.SynchronizerDaemonImpl.execute
79.9% - 44,375 kB - 654,219 alloc. 
      com.envisn.nv.sync.SynchronizerDaemonImpl.doActiveSync

I was going to try upgrading but looking at the cron block in 2.1.8 nothing
has changed except for setting some request attributs in setup().
 
Tracking this down is beyond by skills right now.  Would anyone have some
ideas on the problem or an alternate scheduling solution?
 
Thanks for any advice,
Gary


Mime
View raw message