Develop Reference

How to handle exceptions with spring-jms

Hi I am using a jmslistener annotation to recieve messages from tibco queue. I am DefaultJmsListenerContainer factory with sessionTransacted = true. What I want to do is
When we get a RunTimeException I want to retry the specific message specific no of times(lets say x)
When we get cannot get jdbc connection I want to shutdown the system and want to make sure that this message is sent back to the queue to be redelivered the next time system is brought up.
What I am facing is
When I am setting sessionTransacted as true and I am throwing a RunTimeException the message is redelivered indefinitely . How can I set this configuration to redeliver the message only x times.( I have tried using message header property JMSXDeliveryCount but that does not give me the correct no of times a specific message is redelivered.)
I tried shutting down the system using System.exit(1) but this leads to deadlock and application hangs. I added another piece of code where I am shutting down the application in a different thread and making sure if in between the shutting down of the container another message is read by the listener I throw a RunTimeException so that I am able to get that message again once my system is brought up. However what I want is the 1st message for which we did not get the jdbc connection to be redelivered and no other messages to be read when I stop the container.How can we achieve this.

Paho-Mqtt Publish from callback messageArrived()

I have an application using MQTT implemented with the paho-mqtt-1.0.2 and I am using ActiveMQ as the broker. I have a class implementing the MqttCallback, what I am wondering is why does the client hang
#Override
messageArrived(...)
do work
mqtt.publish(TOPIC,PAYLOAD,2,false) <- here
I want to send a "response" message to the broker for the next step of the work to be done. Similar to this, I read in the docs for that callback function
It is possible to send a new message within an implementation of this callback (for example, a response to this message), but the implementation must not disconnect the client, as it will be impossible to send an acknowledgment for the message being processed, and a deadlock will occur.
Has anyone out there tried doing the above and get it to work?
I also tried using the MqttAsyncClient and that ended up with
"Error too many publishes in progress" leading to undelivered messages.
I know how to get around this issue, I'm not looking for workaround; I'm looking for receiving and publishing on the thread where messageArrived() gets executed.
Happy Hunting!

JMS AutoAcknowledge when using Message Consumer

I have a situation in which the I'm reading messages from a queue using a message consumer (javax.jms.MessageConsumer) .
The session used is using AUTO_ACKNOWLEDGE mode.
From what I've read so far on AUTO_ACK mode:
In auto acknowledgement if the consumer's onMessage() method completes without error the message is considered received and processed successfully, it'll be then removed from the JMS server.
My question is when is the message considered to be ACK by the JMS producer considering I`m not using an MDB that has an onMessage() method but reading the messages by using the message consumer described earlier.
Is the message ACK'ed once I successfully read it using the messageConsumer ?
What will happen if further down the logic-chain a method that uses the respective message will throw an error ? Will the message already be ACK'ed by that time ?

The Javadoc for the AUTO_ACKNOWLEDGE constant says this:
With this acknowledgment mode, the session automatically acknowledges
a client's receipt of a message either when the session has
successfully returned from a call to receive or when the message
listener the session has called to process the message successfully
returns.
I suspect you are calling receive on the MessageConsumer (although you don't explicitly state that) so if you set AUTO_ACKNOWLEDGE it is acknowledged by the time receive returns.
Of course if you have a transacted session then the acknowledge mode is ignored and the message isn't considered received until the session is committed.

Kafka - producer - handle "failed to send"

I'm running a 0.8 Kafka, and build a producer using the provided Java API.
The API functions of sending a message (or messages) return void.
Is there a way to get the status of the sent message? If it sent or failed?
This is extremely important to us since we are reading the messages from a file and we want to delete the file after all messages were sent. But if there were errors and some messages weren't sent and I delete the file it will cause a loss of a very important data.

You can configure your producer to wait until it gets n acks from the Kafka cluster (request.required.acks) so that you have some kind of guarantee that the data has been committed properly before deleting your source file.
If really you need to be sure that the message sent succeeded, you might want to consider the alternative of making the producer to be synchronous (producer.type=sync). This way, you would be able to catch any exception thrown by the blocking invocation and act accordingly. The exception thrown by send() is kafka.common.FailedToSendMessageException.
Kafka's Java API is not ideal, hope this helps you.

JMS MockTopic message not picked up by message listener?

I am trying to write a jUnit test to show that a JMS Subscriber's start() function kicks off the message listener for a Topic (and that messages were not being consumed before start() was called).
I am running into an issue where messages placed on the Topic before the start() function is called are not processed once start() is called. Messages placed on the Topic after start() is called are processed immediately.
MockTopic topicWriter = getMockTopic(TOPIC);
// publish a message for the listener to pick up
MockObjectMessage objectMessage = new MockObjectMessage(message);
objectMessage.setBooleanProperty("Broadcast", true);
topicWriter.addMessage(objectMessage);
// the message doesn't get consumed because the subscriber has not been started
//...assert that the message is not processed... (**SUCCEEDS**)
// start the subscriber/listener
subscriber.start();
//...assert that the messages sitting on the topic get processed... (**FAILS**)
// publish a message for the listener to pick up
topicWriter.addMessage(objectMessage);
//...assert that the message gets processed... (**SUCCEEDS**)
While this shows that the listener is not running before start(), kicking off the message listener should cause all messages currently on the Topic to be processed.
I've attempted to make sure that persistency wasn't the cause by adding:
objectMessage.setJMSDeliveryMode(DeliveryMode.PERSISTENT);
but this did not help.
Actually running the program seems to indicate that messages currently residing on the Topic are processed on start(). Does anyone know why the messages currently on the MockTopic might not be getting processed at start()? Is it a limitation of MockTopic?

I'm not totally clear if this is a MockTopic issue, but with respect to standard JMS, you would not expect a started listener to receive messages published before it started unless it was a durable subscription. The persistence is neither here nor there.