As far as I know there is only AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE possible with MDB.
I would like to have something like CLIENT_ACKNOWLEDGE to avoid XA transactions.
Basically what I want:
get a message --> start local transaction --> perform db operations --> end local transaction --> ack message
Do you know how to achieve this?
Currently i use Jboss 5.1.GA.
I found compenhensive description of MDB strategies here.
AFAIK there is no way to perform ack manually, but if we use Bean Managed Transaction, the ack won't occure in case of exception in onMessage method.
So we can start and finish our transaction 'manually' and in case of exception our message won't be ack.
Related
For a guaranteed message receiver, in an ACK-based protocol like Apache Kafka, TIBCO EMS/RVCM, IBM MQ and JMS there is a way to explicitly acknowledge the receipt of a message. Explicit Acks are not just automatically sent when you return from a dispatcher's callback but an extra method on the session or message to say "I've processed this message". The reason for the existence of this explicit ack is that you can safely queue received messages to be processed by another thread at a later time and then only call this explicit-ack method once your are really done processing this message (safely storing to DB, forwarding to another MOM, etc.) Having this explicit method ensures that you are not losing messages even when you crash after receiving messages but didn't process them yet.
Now with QuickFIX/J (of FIX in general) I know it's not ACK-based but instead persists the last received SeqNum in a file and instead of sendings Acks, message guarantee is achieved by sending ResendRequests for missed SeqNums. But still, is there a way to tell the QuickFIX/J API "I don't automatically want you to persist this last SeqNum once I exit this onMessage() callback but hold off until I tell you so". In other words is there a Session variation which doesn't persist SeqNums automatically and then I can call something on the FIX message to persist this last Seqnum once I've really processed/saved that message ?
(If this feature doesn't exist I think it would be a good addition to the API)
I have a question about MSMQ. If I use a non-transactional queue and send message to it with recoverable parameter, message is stored on disc and in case of some problem secure. But if I want pull message from non-transactional queue, is there some mechanism to secure messages to stay in queue in case of some problem (server error, db off...)?
For some reasons I don't want to use transactional queue. Thanks a lot for response.
You could implement a peek-then-receive process to simulate a transaction.
Peek message to get content.
Use the content as you wish.
If step 2 completes then Receive message to effectively delete it.
If step 2 fails, execute cleanup code and goto step 1.
I have an issue when I want a return my data to a queue when my service is down, after reading batch with data. If I goos understood in amqp I can use acknowledge, but in spring bath documentation I don't see any information about that. Also, I check the source code for AmqpItemReader and I don't see any flow for acknowledge. Do I need to implement custom ItemReader with this flow or missed something?
The AmqpItemReader uses a simple RabbitTemplate.receive() operation which acks the message immediately, unless it is running in a transaction.
The only way to control the acks is to use transactions (with a RabbitTransactionManager).
The transaction manager will ack or requeue the message if the transaction is committed or rolled-back, respectively.
I am using the HornetQ for jms in Jboss 5.1.0 environment. I have various queues, each has its re-delivery count and delays configured in the hornetq-configuration.xml. If the messages cannot be processed in the given retry count then they are moved into a common queue "/jms/deadqueue". An mdb of this deadqueue will process all the messages. Before moving into a deadqueue I wish to add an additional property into that message(I use ObjectMessage). Is that possible?
and also, Is it possible to get current attempted count inside the mdb onmessage method, that is, if the message is redelivered 2nd time I should get 2?
regards
V
Check out the new book on HornetQ
http://www.amazon.com/dp/1849518408/?tag=packtpubli-20
I'm developing a solution to retrieve poison messages from a backout queue in Websphere 6.1.
My question is: when this msg (ie. TextMessage) is re-queue from a regular queue to backout queue, what is the queue name in msg.getJMSDestination() and msg.getJMSReplyTo()?
For example:
I've got a msg with destination to myQueue. However, for some reason, this msg could not be processed (poison message) and, because websphere is configured for that, this msg is re-queued to backout queue named myBOQueue. If I retrieve this msg from myBOQueue (using MDB), and I execute ((Queue) msg.getJMSDestination()).getQueueName(), what do i go: myQueue or myBOQueue? And if I execute ((Queue) msg.getJMSReplyTo()).getQueueName(), what do I got?
Message document: http://download.oracle.com/javaee/1.4/api/javax/jms/Message.html
Thx,
Andre
You want to look in vendor-specific docs. I think retry counts and poison message queues are a vendor-specific feature not included in the JMS spec.