We Keep Coding

Cancel ActiveMQ message

I'm not sure if ActiveMQ is a right tool here...
I have a task queue and multiple consumers, so my idea was to use ActiveMQ to post tasks, which are then consumed by consumers.
But I need to be able to cancel the task, if it was not processed yet...
Is there an API for removing Message from Queue in ActiveMQ?
Destination destination = session.createQueue(TOPIC_NAME);
MessageProducer producer = session.createProducer(destination);
ObjectMessage message = session.createObjectMessage(jobData);
producer.send(message);
...
producer.cancel(message); (?)
The use-case is that, for any reason, performing the task is no longer needed, and the task is resource-consuming.

What about setting an expiry time on the message?
http://activemq.apache.org/how-do-i-set-the-message-expiration.html
If you want a message to be deleted if it has not been processed / consumed in a particular time frame, then message expiry seems the answer to me.

ActiveMQ exposes a JMX interface that allows for operations of this kind. The MBean that models a Queue (e.g., org.apache.activemq:type=broker,brokerName=amq,destinationType=Queue,destinationName=my_queue) exposes a method removeMessage (String id). There are also methods that remove messages that match a particular pattern.
So far as I know, this functionality is not exposed outside JMX.
But...
I have a nasty feeling that JMX operations that work on specific messages only work on messages that are paged into memory. By default that would usually be the 400 messages nearest the head of the queue. I know this is true for selector operations, although I'm not sure about JMX.
Some ActiveMQ message stores (e.g., the JDBC store) might also provide a way to get to the underlying message data and manipulate it. On a relational database this is usually safe to do, because messages that are 'in flight' in a JMS operation will be locked at the database level. However, this is a lot of hassle for what ought to be a simple job.
I wonder if JMS is really the right technology for this job? It isn't really intended for random access. Perhaps some sort of distributed data cache would work better (jgroups, Hazelcast,...)?

For those who are looking for a direct answer, there's a JMS API to control this behaviour:
Per JMS API docs:
setTimeToLive(long timeToLive)
Specifies the time to live of messages that are sent using this JMSProducer.
So you can set this value on the producer before sending:
...
producer.setTimeToLive(30000L);
producer.send();
With this particular setting, messages will be retained for 30 seconds before being deleted by the Message Broker

Best Practice for resilience of messages across RabbitMQ queues

I am trying to understand the best use of RabbitMQ to satisfy the following problem.
As context I'm not concerned with performance in this use case (my peak TPS for this flow is 2 TPS) but I am concerned about resilience.
I have RabbitMQ installed in a cluster and ignoring dead letter queues the basic flow is I have a service receive a request, creates a persistent message which it queues, in a transaction, to a durable queue (at this point I'm happy the request is secured to disk). I then have another process listening for a message, which it reads (not using auto ack), does a bunch of stuff, writes a new message to a different exchange queue in a transaction (again now happy this message is secured to disk). Assuming the transaction completes successfully it manually acks the message back to the original consumer.
At this point my only failure scenario is is I have a failure between the commit of the transaction to write to my second queue and the return of the ack. This will lead to a message being potentially processed twice. Is there anything else I can do to plug this gap or do I have to figure out a way of handling duplicate messages.
As a final bit of context the services are written in java so using the java client libs.
Paul Fitz.

First of all, I suggest you to look a this guide here which has a lot of valid information on your topic.
From the RabbitMQ guide:
At the Producer
When using confirms, producers recovering from a channel or connection
failure should retransmit any messages for which an acknowledgement
has not been received from the broker. There is a possibility of
message duplication here, because the broker might have sent a
confirmation that never reached the producer (due to network failures,
etc). Therefore consumer applications will need to perform
deduplication or handle incoming messages in an idempotent manner.
At the Consumer
In the event of network failure (or a node crashing), messages can be
duplicated, and consumers must be prepared to handle them. If
possible, the simplest way to handle this is to ensure that your
consumers handle messages in an idempotent way rather than explicitly
deal with deduplication.
So, the point is that is not possibile in any way at all to guarantee that this "failure" scenario of yours will not happen. You will always have to deal with network failure, disk failure, put something here failure etc.
What you have to do here is to lean on the messaging architecture and implement if possibile "idempotency" of your messages (which means that even if you process the message twice is not going to happen anything wrong, check this).
If you can't than you should provide some kind of "processed message" list (for example you can use a guid inside every message) and check this list every time you receive a message; you can simply discard them in this case.
To be more "theorical", this post from Brave New Geek is very interesting:
Within the context of a distributed system, you cannot have
exactly-once message delivery.
Hope it helps :)

How to publish to multiple queues with work queue behavior?

Using RabbitMQ, I have two types of consumers: FileConsumer writes messages to file and MailConsumer mails messages. There may be multiple consumers of each type, say three running MailConsumers and one FileConsumer instance.
How can I do this:
Each published message should be handled by exactly one FileConsumer instance and one MailConsumer instance
Publishing a message should be done once, not one time for each queue (if possible)
If there are no consumers connected, messages should be queued until consumed, not dropped
What type of exchange etc should I use to get this behavior? I'd really like to see some example/pseudo-code to make this clear.
This should be easy to do, but I couldn't figure it out from the docs. It seems the fanout example should work, but I'm confused with these "anonymous queues" which seems like it will lead to sending same message into each consumer.

If you create queue without auto-delete flag, then queues will stay alive even after consumers disconnection.
Note, that if you declare queue as persistent, it will be present even after broker restart.
If you will publish then messages with delivery-mode=2 property set (that mean that message will be persistent), such messages will stay in persistent (this is important to make queue persistent) queues even after broker restart.
Using fanout exchange type is not mandatory. You can also use topic for better message routing handling if you need that.
UPD: step-by-step way to get what you show with schema.
Declare persistent exchange, say main, as exchange.declare(exchange-name=main, type=fanout, durable=true).
Delcare two queues, say, files and mails as queue.declare(queue-name=files, durable=true) and queue.declare(queue-name=mails, durable=true)
Bind both queues to exchange as queue.bind(queue-name=files, exchange-name=main) and queue.bind(queue-name=mails, exchange-name=main).
At this point you can publish messages to main exchange (see note about delivery-mode above) and consume with any consumer number from queues, from files with FileConsumer and from mails with MailConsumer. Without any consumers on queues messages will be queued and stay in queue until they consumed (or broker restart is they are not persistent).

How to guarantee JMS reliable delivery

I think plenty of (Spring in my case) applications using JMS may follow this workflow:
Database A ===> Producer ===> JMS Queue ===> Consumer ===> Database B
then reliability is a concern. Let's say if when a data record in Database A should always be marked as delivered, when the message contains the data record is truely consumed and persist the data in Database B. Then there are questions:
From my knowledge, currently JMS protocol does not define any functions to send acknowledgement from consumer to producer, but only to MOM, so the actual consumer-to-producer acknowledgement methods vary by JMS provider. So does it mean there is no way to develop a mechanism for such acknowledgement that can work for generally all JMS products(ActiveMQ, WebSphere MQ and Jboss MQ)?
Consider the scenario of a blackout, then does it make the messages in the queue just evaporate so need to resend? or different JMS products can pick up what is left, as the messages are Serialized, so that missing message can be only caused by transaction management or async/sync configuration but not because of application server is down?

JMS guarantees the delivery of the message by nature, if the message is posted, then it will delivered to a consumer if there is one, whatever happen, the MOM is designed to ensure this fact. Anyway, delivered does not necessary mean processed.
Reliability is ensured by various mechanism :
the first one is the persistence of message in the queue (the queue AND the message must be flagged as persistent, which is the default value) which ensure that message will not be lost in case of system interruption.
then you have the acknowledgement and the retry policy, message will be kept in the queue until consumer acknowledge it and in case of transacted session, will be redelivered until consumer effectively processed the message or max retry is reached. Failed message can then be redirected to a dead letter queue for analysis.
To ensure the coherency between the two datasources you have to use XA transaction at least on the producer side (you have at least 2 resources implied in the transaction database A and JMS queue) in order to guarantee that the message will not be posted to the queue if the commit in database A fails or the database will not be updated if the post to the queue fails. Message consumption should be transacted too to ensure redelivery in case of rollback.
The transaction boundaries will never include both consumer and producer because it conflicts with the asynchronous nature of the messaging system, you can't afford to lock the resources on the producer side until the consumer process the message because you have no guarantee on when it will happen.
NB : in the event that your database does not support XA (or to improve performance) and if you have only 2 resources implied in the transaction (database and JMS queue) you can have a look to Logging Last Resource Transaction Optimization

1) From my experience with queue managers (MQ Series, ActiveMQ and HornetQ) I never needed this kind of acknowledgement between producer/consumer. Also the environment that I used to deal with, the traffic was about 50/60 million per day of objects on several queues. And the queues are all persisted as well.
2) In my case, using the persistence mechanism on queue manager was totally sufficient to handle a blackout scenario. I used disk persistence on MQ Series and HornetQ.
However, sometimes to ack the amount of messages, we developed some mechanisms to compare Database A with Database B, to be sure that messages were consumed as well. I don't know if JMS architecture should provide this kind of mechanism, because such task could decrease the performance.
It's something - in my point of view - that you have to measure on your system architecture how important is to match this information, because it's not that easy to keep.
Regards.

If I understand your question, this seems like a case for JTA/XA transactions (as long as your DB/JMS vendors support them). Spring TX managers can help make the tx management (more) vendor agnostic.
FYI, I use Apache Camel for this type of flow which has pretty good error handling across producers/consumers.

jms call to message.acknowledge() after exiting onMessage()

I want to concurrently consume jms messages from multiple queues. All the messages should go to the DB after long running processing and I have no right to lose them.
Question: Is it possible to save messages for future acknowledgement and call oldMessage.acknowledge() when another message is being processed?
My first guess is that this is impossible since it is deep in the jms processing unit and I have to process message and acknowledgement within an onMessage(...) method.
Second guess is to split onMessage() concurrently and allow long running processing for many messages. But this is not a good option since I have to ensure that all messages are coming ordered!
2nd question: Is there any way to ensure the incoming order while concurrency processing?

1: JMS has a flag on Session that is *CLIENT_ACKNOWLEDGE* you can see it here. I never used it but seems to do what you want.
2:
2.1: You have N consumers for the same queue: You can explore the Exclusive Consumer that some implementations have support. (for AtiveMQ: here).
2.2 You have 1 consumer per queue but you want to order all messages from all queues.
You can use the concept of an ordered SlackBuffer.
You can explore another possibilities like: Redirect all messages to an output queue that maintains the order of messages and you will only consume messages from that single output queue. The order of messages and the redirection are accomplished by the MQ server. It is only a valid idea if you can control the MQ server.
I hope this can help