JMS + SimpleRetryConnectionStrategy +JNDI +OracleJMS ... not working

Guys,

I am using Mule to connect to an oracle JMS provider. Below is the configuration for the connector:
        <connector name="oracleJmsCustomerConnector" className="org.mule.providers.jms.JmsConnector">
                <properties>
                        <property name="jndiProviderUrl" value="opmn:ormi://host:OC4J_SOJMS"/>
                        <map name="jndiProviderProperties">
                                <property name="java.naming.factory.initial" value="com.evermind.server.rmi.RMIInitialContextFactory"/>
                                <property name="java.naming.security.principal" value="admin"/>
                                <property name="java.naming.security.credentials" value="welcome"/>
                        </map>
                        <property name="connectionFactoryJndiName" value="java:comp/resource/SOJMSDS/QueueConnectionFactories/customers_qt"/>
                        <property name="jndiDestinations" value="true"/>
                        <property name="forceJndiDestinations" value="true"/>
                </properties>
                <connection-strategy className="org.mule.providers.SimpleRetryConnectionStrategy">
                        <properties>
                                <property name="retryCount" value="5"/>
                                <property name="frequency" value="1800000"/>
                                <!-- see http://jira.symphonysoft.com/browse/MULE-708 -->
                                <property name="doThreading" value="true"/>
                        </properties>
                </connection-strategy>
        </connector>

This works like a charm. Somewhere during the night, Mule loses its connection. Not sure what happens on the oracle side, so don't ask ;)

The SimpleRetryConnectionStrategy is configured to try a few times to establish the connection again. This fails, even when oracle is back.

Due to historical reasons, I'm still using 1.3rc4, which was the last release candidate before 1.3 was released. Below is a stacktrace:
ERROR 2007-02-17 01:52:23,643 [UMOManager.4] org.mule.providers.SimpleRetryConnectionStrategy: Failed to connect/reconnect on endpoint: jms:///?address=java:comp/resource/SOJMSDS/Queues/customers_q. Root Exception was: Failed to look up destination: Disconnected: Connection reset(JMS Code: null). Type: class javax.jms.JMSException
org.mule.providers.ConnectException: Initialisation Failure: Failed to look up destination: Disconnected: Connection reset
        at org.mule.providers.jms.SingleJmsMessageReceiver.createConsumer(SingleJmsMessageReceiver.java:197)
        at org.mule.providers.jms.SingleJmsMessageReceiver.doConnect(SingleJmsMessageReceiver.java:69)
        at org.mule.providers.AbstractMessageReceiver.connect(AbstractMessageReceiver.java:344)
        at org.mule.providers.SimpleRetryConnectionStrategy.doConnect(SimpleRetryConnectionStrategy.java:51)
        at org.mule.providers.AbstractConnectionStrategy$1.run(AbstractConnectionStrategy.java:53)
        at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1486)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:391)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:865)
        at org.mule.impl.work.WorkExecutorPoolImpl.execute(WorkExecutorPoolImpl.java:88)
        at org.mule.impl.work.ScheduleWorkExecutor.doExecute(ScheduleWorkExecutor.java:35)
        at org.mule.impl.work.MuleWorkManager.executeWork(MuleWorkManager.java:272)
        at org.mule.impl.work.MuleWorkManager.scheduleWork(MuleWorkManager.java:241)
        at org.mule.providers.AbstractConnectionStrategy.connect(AbstractConnectionStrategy.java:44)
        at org.mule.providers.AbstractMessageReceiver.connect(AbstractMessageReceiver.java:338)
        at org.mule.providers.SimpleRetryConnectionStrategy.doConnect(SimpleRetryConnectionStrategy.java:51)
        at org.mule.providers.AbstractConnectionStrategy$1.run(AbstractConnectionStrategy.java:53)
        at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1486)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:391)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:865)
        at org.mule.impl.work.WorkExecutorPoolImpl.execute(WorkExecutorPoolImpl.java:88)
        at org.mule.impl.work.ScheduleWorkExecutor.doExecute(ScheduleWorkExecutor.java:35)
        at org.mule.impl.work.MuleWorkManager.executeWork(MuleWorkManager.java:272)
        at org.mule.impl.work.MuleWorkManager.scheduleWork(MuleWorkManager.java:241)
        at org.mule.providers.AbstractConnectionStrategy.connect(AbstractConnectionStrategy.java:44)
        at org.mule.providers.AbstractMessageReceiver.start(AbstractMessageReceiver.java:375)
        at org.mule.providers.AbstractConnector.startConnector(AbstractConnector.java:334)
        at org.mule.providers.AbstractConnector.connect(AbstractConnector.java:924)
        at org.mule.providers.SimpleRetryConnectionStrategy.doConnect(SimpleRetryConnectionStrategy.java:51)
        at org.mule.providers.AbstractConnectionStrategy$1.run(AbstractConnectionStrategy.java:53)
        at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1486)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:391)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:865)
        at org.mule.impl.work.WorkExecutorPoolImpl.execute(WorkExecutorPoolImpl.java:88)
        at org.mule.impl.work.ScheduleWorkExecutor.doExecute(ScheduleWorkExecutor.java:35)
        at org.mule.impl.work.MuleWorkManager.executeWork(MuleWorkManager.java:272)
        at org.mule.impl.work.MuleWorkManager.scheduleWork(MuleWorkManager.java:241)
        at org.mule.providers.AbstractConnectionStrategy.connect(AbstractConnectionStrategy.java:44)
        at org.mule.providers.AbstractConnector.connect(AbstractConnector.java:899)
        at org.mule.providers.SimpleRetryConnectionStrategy.doConnect(SimpleRetryConnectionStrategy.java:51)
        at org.mule.providers.AbstractConnectionStrategy$1.run(AbstractConnectionStrategy.java:53)
        at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.jms.JMSException: Failed to look up destination: Disconnected: Connection reset
        at org.mule.providers.jms.Jms11Support.getJndiDestination(Jms11Support.java:139)
        at org.mule.providers.jms.Jms11Support.createDestination(Jms11Support.java:118)
        at org.mule.providers.jms.SingleJmsMessageReceiver.createConsumer(SingleJmsMessageReceiver.java:169)
        ... 46 more

Correct me if I'm wrong, but upgrading to 1.3.3 will not fix my problem, I think. I have been looking through the code and I think the root cause of the problem is the fact that I'm not only loosing the connection with my JMSProvider, but also with the JNDI store (hosted on the same machine).
Could it be that the retry strategy is not refreshing its connection with the JNDI store? If so, how can I make sure that the retry strategy refreshes its connection with the JNDI store and _then_ tries to connect with the JMS queues again.
Thanks in advance.

P.S.: I've been searching this list about retry strategies and JMS, but haven't found a similar problem yet.