AMQ 4.1 + Jencks 1.3: queued messages not delivered

[Renaud Bruyeron <br...@fullsix.com>]

I am running into problems with the the 20060830 snapshot of AMQ 4.1.
I use this version inside servicemix-3.0 final (by replacing the 
activemq jars and the activeio one with the ones from 4.1), which uses 
jencks 1.3. I need the jdbc-master-slave mode, which is a 4.1-only feature
afaik.

I am running into this situation where messages are queued, and 
sometimes some of them are not delivered into the message listener.
I use the MDP approach and set the concurrency to 1 (only one listener
on each subscription):

	<!-- the JCA container -->
	<bean id="jencks" class="org.jencks.JCAContainer"
		singleton="true">

		<!-- lets use the default servicemix BootstrapContext (from JNDI) -->
		<property name="bootstrapContext" ref="bootstrapContext"/>

		<!-- the JCA Resource Adapter -->
		<property name="resourceAdapter" ref="activeMQResourceAdapter" />
	</bean>
	<bean id="activeMQResourceAdapter"
		class="org.apache.activemq.ra.ActiveMQResourceAdapter"
		singleton="true">
		<property name="serverUrl" value="${activemq.connection.url}" />
	</bean>

	<bean name="jcaEndpoint"
		class="org.jencks.JCAConnector">
		<property name="jcaContainer" ref="jencks" />
		<!-- subscription details -->
		<property name="activationSpec">
			<bean
class="org.apache.activemq.ra.ActiveMQActivationSpec">
				<property name="destination" value="mmx.queue.sms" />
				<property name="destinationType"
					value="javax.jms.Queue" />
				<property name="maxSessions" value="1"/>
				<property name="maxMessagesPerBatch" value="5"/>
			</bean>
		</property>
		<!-- use XA transactions -->
		<property name="transactionManager" ref="userTransaction" />
		<property name="ref" value="myEndpoint" />
	</bean>


If I kill off the JCA container and restart it, the "stuck" messages are 
delivered normally. When messages are stuck, other messages can make it 
through the queue, therefore it is not an issue with the connection 
itself. It looks like something's wrong in the way the consumers 
maintain their states. Resetting that state (i.e. restarting the JVM) 
fixes the problem.

Any idea what could be wrong?

  - Renaud