Redelivery of messages in JCAPS + WebSphere App Server

Question

I have a POJO that runs on WebSphere Application Server 6.1 and connects to a JCAPS 5.1.X queue using JMS API. JCAPS has been configured as a 'Generic JMS provider' in WebSphere and the queues and QCFs configured via WAS' admin console. The POJO is picking the messages and processing it just fine.
Now while processing the message, in case of failures, I need to reprocess the message 'n' number of time after a certain delay and move it to a DLQ if all attempts fail, which from my understanding is standard JMS stuff. Reading through the JCAPS documentation it appears that it does support this.
My question is how would I configure these details in WebSphere's JMSProvider/QCF/Q configuration. I have tried adding these as 'custom properties' of QCF in admin console, but that did not work:
JMSJCA.redeliveryhandling=5:1000;10:5000;50:move(qu eue:mydlq)
redeliveryhandling=5:1000;10:5000;50:move(queue:myd lq)
This the code snippet from the POJO that receives the events:
while (count > 0) {
queueSession = queueConnection.createQueueSession(true, -1);
controlQueue = getQueue(QUEUE_NAME, queueSession);
queueReceiver = queueSession.createReceiver(controlQueue);
queueConnection.start();
TextMessage message = (TextMessage) queueReceiver.receive();
count--;
System.out.println("EventReceiver "
+"Received synchronize message; "+ message.getText()
+" expect "+ count + " more");
//If the message body has "throw" in it then roll it back. The
//message should go back to the queue and then be redelivered by
//the JMS Provider.
if ("throw".equals(message.getText())) {
queueSession.rollback();
} else {
queueSession.commit();
}Any help would be greatly appreciated.
PS: The code snippet is from an example I found somewhere on the web.

Answer 1

My knowledge is that if you want to make use of those specific JMSJCA features you need to deploy the RA, configure a connection pool and consume messages through a MDB, not a POJO. I don't know how your POJO is getting the JMS connection, but I doubt is using any RA feature this way, as it is not the JMSJCA RA which is actually handling your connections. These are just my 5 cents, maybe you could ask more specific JMSJCA questions to their mailing list.