Atomikos Forum

MessageDrivenCont. - Unsubcribe fails: Durable Consumer in use

Using the message driven container i'll want to unsubscribe my durable topic subscription on context shutdown.

    <bean id="jmsMessageContainer" class="com.atomikos.jms.extra.MessageDrivenContainer"
        init-method="start" destroy-method="stop">
        <property name="atomikosConnectionFactoryBean" ref="jmsConnectionFactory" />
        <property name="destination" ref="testTopic" />
        <property name="messageListener" ref="jmsHome" />
        <property name="subscriberName" value="test" />
        <property name="unsubscribeOnClose" value="true" />

But this fails - using ActiveMQ as Provider - with this Exception:

2010-03-25 08:38:48,200 [Thread-3]      WARN  atomikos - MessageConsumerSession: unsubscribing test-0...
2010-03-25 08:38:48,222 [Thread-3]      WARN  atomikos - Error delegating call to unsubscribe on JMS driver
javax.jms.JMSException: Durable consumer is in use
    at org.apache.activemq.command.RemoveSubscriptionInfo.visit(
    at org.apache.activemq.transport.TransportFilter.onCommand(
    at org.apache.activemq.transport.WireFormatNegotiator.onCommand(
    at org.apache.activemq.transport.InactivityMonitor.onCommand(
    at org.apache.activemq.transport.TransportSupport.doConsume(
    at org.apache.activemq.transport.tcp.TcpTransport.doRun(
2010-03-25 08:38:48,227 [Thread-3]      WARN  atomikos - atomikos connection pool 'jmsFactory1': destroying pool...

Something known about this problem - any workaround available?
Torsten Krah Send private email
Thursday, March 25, 2010

I guess the unsubscribe needs to wait for the thread to finish. This is not a very commonly used feature, but I have scheduled a bug fix for it.

Guy Pardon Send private email
Thursday, March 25, 2010
3.6.5 does wait for the thread to shutdown, but it does not close the open receiver if the thread is going to shutdown - unsubscribe still fails because the consumer is still in use.
This patch:

does fix this, which will close the receiver if there is one when the thread is going to die.
Torsten Krah Send private email
Tuesday, April 27, 2010
Did found some side effect of the blocking receive call.
In unit tests we have a TxTimeout of 100 - the receive call does wait 100 * 1000 / 2 - this is a long time.
Each testcase will now wait on context shutdown a long long time until thread.join() will succeed when the container is shutdown (with 3.6.5).
Thread.interrupt() maybe a way to interrupt the receive call if the Container is shutdown - but this may need more work on the code to handle the resulting JMSException gracefully - or what to do against those long long shutdown time?
Torsten Krah Send private email
Thursday, April 29, 2010

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics