You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by slew77 <st...@yahoo.co.uk> on 2015/10/14 14:24:31 UTC
Artemis - all messages go to "Delivering" after a client crash
Hi,
We have an Artemis server (1.1.0) with a transacted consumer.
The consumer is an Apache Camel (2.15.2) route running in Karaf 3.0.4. We
are using the ActiveMQ 5.12.0 libraries.
Within the transaction, the message is marked as being delivered (i.e.
accessible from listDeliveringMessages), however, if the consumer crashes
before commiting, the message stays with this status. This means, after the
application starts, and tries to consume from the queue it doesn't get that
message. This status never seems to update, leaving the message in limbo.
Further, if we send any new requests to the same queue, they all get marked
as being delivered - even if the application hasn't been restarted yet.
After the crash, the server correctly shows that there are 0 connections.
However, the queue still thinks there are consumers.
The only way to get things going again is to restart the broker.
If I change the consumer to not use transactions and set the acknowledge
mode to CLIENT_ACKNOWLEDGE, then I get the same behaviour.
Any help would be appreciated.
Steve.
This is the camel queue configuration:
<bean id="activemq"
class="org.apache.activemq.camel.component.ActiveMQComponent">
<property name="connectionFactory" ref="poolConnectionFactory"/>
<property name="transacted" value="true"/>
<property name="transactionManager" ref="jmsTransactionManager"/>
<property name="cacheLevelName" value="CACHE_CONSUMER" />
</bean>
<bean id="jmsTransactionManager"
class="org.springframework.jms.connection.JmsTransactionManager">
<property name="connectionFactory" ref="poolConnectionFactory"/>
</bean>
<bean id="poolConnectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory" init-method="start"
destroy-method="stop">
<property name="maxConnections" value="${activemq.maxConnections}"/>
<property name="connectionFactory" ref="jmsConnectionFactory"/>
<property name="idleTimeout" value="0"/>
</bean>
<bean id="jmsConnectionFactory"
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="${activemq.brokerURL}"/>
</bean>
<bean id="required"
class="org.apache.camel.spring.spi.SpringTransactionPolicy">
<property name="transactionManager" ref="jmsTransactionManager"/>
<property name="propagationBehaviorName"
value="PROPAGATION_REQUIRED"/>
</bean>
This is the broker config:
<?xml version='1.0'?>
<configuration xmlns="urn:activemq"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:activemq
/schema/artemis-configuration.xsd">
<jms xmlns="urn:activemq:jms">
<queue name="DLQ"/>
<queue name="ExpiryQueue"/>
</jms>
<core xmlns="urn:activemq:core">
<journal-type>ASYNCIO</journal-type>
<paging-directory>./data/paging</paging-directory>
<bindings-directory>./data/bindings</bindings-directory>
<journal-directory>./data/journal</journal-directory>
<large-messages-directory>./data/large-messages</large-messages-directory>
<journal-min-files>10</journal-min-files>
<journal-buffer-timeout>64000</journal-buffer-timeout>
<acceptors>
<acceptor
name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576</acceptor>
<acceptor name="amqp">tcp://0.0.0.0:5672?protocols=AMQP</acceptor>
<acceptor
name="stomp">tcp://0.0.0.0:61613?protocols=STOMP</acceptor>
<acceptor
name="hornetq">tcp://0.0.0.0:5445?protocols=HORNETQ,STOMP</acceptor>
<acceptor name="mqtt">tcp://0.0.0.0:1883?protocols=MQTT</acceptor>
</acceptors>
<security-settings>
<security-setting match="#">
<permission type="createNonDurableQueue" roles="amq"/>
<permission type="deleteNonDurableQueue" roles="amq"/>
<permission type="createDurableQueue" roles="amq"/>
<permission type="deleteDurableQueue" roles="amq"/>
<permission type="consume" roles="amq"/>
<permission type="send" roles="amq"/>
<permission type="manage" roles="amq"/>
</security-setting>
</security-settings>
<address-settings>
<address-setting match="#">
<max-size-bytes>104857600</max-size-bytes>
<page-size-bytes>10485760</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
</address-setting>
</address-settings>
</core>
</configuration>
--
View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-all-messages-go-to-Delivering-after-a-client-crash-tp4702940.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Artemis - all messages go to "Delivering" after a client crash
Posted by andytaylor <an...@gmail.com>.
yes it should, Openwire is a work in progress and we're filling gaps in
its functionality. Could you raise a Jira?
On 14/10/15 13:47, slew77 [via ActiveMQ] wrote:
> Hi,
>
> If I modify the example project: protocols/openwire/message-listener and
> change the session to CLIENT_ACKNOWLEDGE and update onMessage to call
> message.acknowledge(). If I terminate the process before it has
> acknowledged the messages, then I get similar behaviour. The messages
> remain marked as being delivered and aren't released until the broker is
> restarted. There is one slight difference, as in this test follow up
> messages aren't being marked as "delivered", so it's only the messages
> that were being processed when the crash occurred that are stuck.
>
> This is using the broker that is part of the example project with no
> changes.
>
> Should the broker detect this type of crash and allow the messages that
> didn't get processed to be redelivered?
>
> Thanks,
> Steve.
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Artemis-all-messages-go-to-Delivering-after-a-client-crash-tp4702940p4702944.html
>
> To start a new topic under ActiveMQ - User, email
> ml-node+s2283324n2341805h35@n4.nabble.com
> To unsubscribe from ActiveMQ - User, click here
> <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2341805&code=YW5keS50YXlsczY3QGdtYWlsLmNvbXwyMzQxODA1fC05MDE1NDk1MzM=>.
> NAML
> <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-all-messages-go-to-Delivering-after-a-client-crash-tp4702940p4702946.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Artemis - all messages go to "Delivering" after a client crash
Posted by slew77 <st...@yahoo.co.uk>.
Hi,
If I modify the example project: protocols/openwire/message-listener and
change the session to CLIENT_ACKNOWLEDGE and update onMessage to call
message.acknowledge(). If I terminate the process before it has acknowledged
the messages, then I get similar behaviour. The messages remain marked as
being delivered and aren't released until the broker is restarted. There is
one slight difference, as in this test follow up messages aren't being
marked as "delivered", so it's only the messages that were being processed
when the crash occurred that are stuck.
This is using the broker that is part of the example project with no
changes.
Should the broker detect this type of crash and allow the messages that
didn't get processed to be redelivered?
Thanks,
Steve.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-all-messages-go-to-Delivering-after-a-client-crash-tp4702940p4702944.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.