That is the correct configuration. Recovery is starting before the DefaultJMSProvider is started. As long as that error is not repeated every few minutes, then it is working. Also, when I changed the DefaultDS from hsqldb to another database the error disappeared.
Thanks for the information. I will give it a try.
Totally stupid that it wil throw an exception in this case. I hope that they fix this some day. I don't like it to have 'non-exceptions' in my server.log.
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.
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.