How to clean up uncommit JMS transactions on jboss 4.2.3

[glenwood]

Hi,

I was using jboss HAJMS with a customized PERSISTENT TOPIC, I accidently stop message consuming for a while,which cause my JMS die,when I try to restart jboss server,I found following errors while jboss was trying to deploy jbossmq-httpil.sar under JBOSS_HOME/server/all/deploy-hasinglon/jms

jboss java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.lang.StringCoding.encode(StringCoding.java:266)
at java.lang.String.getBytes(String.java:947)
at java.io.UnixFileSystem.list(Native Method)
at java.io.File.list(File.java:973)
at java.io.File.listFiles(File.java:1051)
at org.apache.axis2.scripting.ScriptRepositoryListener.findServicesInDirectory(ScriptRepositoryListener.java:43)
17:37:43,907 ERROR [STDERR] at org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:225)
17:37:43,907 ERROR [STDERR] at org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryListener.java:324)
17:37:43,907 ERROR [STDERR] at org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepository(SchedulerTask.java:64)
17:37:43,907 ERROR [STDERR] at org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.java:71)
17:37:43,907 ERROR [STDERR] at org.apache.axis2.deployment.scheduler.Scheduler$SchedulerTimerTask.run(Scheduler.java:83)
17:37:43,907 ERROR [STDERR] at java.util.TimerThread.mainLoop(Timer.java:512)
17:37:43,907 ERROR [STDERR] at java.util.TimerThread.run(Timer.java:462)
17:37:43,907 ERROR [STDERR] java.lang.OutOfMemoryError: Java heap space

I think it was caused by JMS uncommit transactions,does anyone know how to clean up those uncommit transactions without reinstalling jboss server,it's very important for me,thanks in advance!
btw,I'm using jboss MQ default db to implement HAMQ.

[adrian.brock]

Uncommitted transactions should be automatically rolled back when you reboot.

The error message is not jms related though so I don't know how you reached the conclusion. It shows the listing of a directory by apache axis having an OOME.

It isn't even a proper OOME, it means your GC is getting stressed
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom

This can be caused by something as simple as too much paging of memory
back and forwards to disk or that your GC isn't tuned properly?

Given that it occurred on the file access, it might also be too many calls to the
finalize() method of java.io.File due to lots of them getting constructed and then thrown away?