Created attachment 479759 [details] Set java max heap to 1024 Description of problem: When a lot of Repo data has to be generated, Taskomatic will crash because of exhaused Heap Space Version-Release number of selected component (if applicable): 1.3 How reproducible: Always (At least when using pgsql) Steps to Reproduce: 1. repo-sync a huge repo or doing a ISS 2. Watch /var/log/rhn/rhn_taskomatic_daemon.log Actual results: Taskomatic crashes Expected results: Updated Repo Data Additional info: excerpt from /var/log/rhn/rhn_taskomatic_daemon.log INFO | jvm 1 | 2011/02/20 12:21:02 | 2011-02-20 12:21:02,802 [Thread-797] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Generating new repository metatada for channel 'sl5x-x86_64'(sha1) 4885 packages, 1447 errata INFO | jvm 1 | 2011/02/20 12:25:44 | Server daemon died! INFO | jvm 1 | 2011/02/20 12:25:52 | Exception in thread "DefaultQuartzScheduler_QuartzSchedulerThread" java.lang.OutOfMemoryError: Java heap space INFO | jvm 1 | 2011/02/20 12:25:54 | Exception in thread "Thread-797" java.lang.OutOfMemoryError: Java heap space ERROR | wrapper | 2011/02/20 12:26:10 | JVM appears hung: Timed out waiting for signal from JVM. ERROR | wrapper | 2011/02/20 12:26:10 | JVM did not exit on request, terminated Setting the max heap to 1024 helps. IMHO it does not make sense to operate spacewalk or satellites on servers with less than 2Gbyte RAM this value should be acceptable.
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Aligning under space16.
I believe Mirek addressed the problem with commit b803f6ef78362eb34d2cfc07ca0c400e40b89dd9 which went to Spacewalk 1.5. Closing as CURRENTRELEASE and reassigning to Mirek, in case this does not address the problem fully.