They are listening. :-)

It is not straightforward to ensure that the recovery code kicks in at the right time. Recovery is attempted  in the background at a periodic interval (which can be configured) but at some point after rebootthe recovery thread  has to check the recovery logs for failures from the last run. It then has to keep checking for transactions which have failed in the current run e.g. because of a timeout form a resource manager.

The first recovery scan cannot wait until all recovery components are initialised because some of them might be delayed indefinitely e.g. because of a resource manager being down. Waiting would stop all other transcations using independent resources from being recovered. So, instead it goes ahead and attemtps to scan the logs and identify the associated resources at the set period, logging failures and trying to resolve them at the next run. You might dislike seeing that initial exception but then again you would not want it to be suppressed if it represented a real failure in the JMS recovery, say because there really was an underlying database problem.

Brad,

What if it is happening every few minutes? What could be the cause of it? I see the error repeatedly in the logs after a cold restart of the VMHost without a graceful stop of the JBoss SOA-P along with some DB connection issues in the log. It seems they have dissappeared after I restart the JBoss service though.