Thanks fot the help i modified the standardjboss.xml and set
<invoker-proxy-binding> <name>message-driven-bean</name> <invoker-mbean>default</invoker-mbean> <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory> <proxy-factory-config> <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI> <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI> <MaximumSize>15</MaximumSize> <MaxMessages>1</MaxMessages> <MDBConfig> <ReconnectIntervalSec>10</ReconnectIntervalSec> <DLQConfig> <DestinationQueue>queue/DLQ</DestinationQueue> <MaxTimesRedelivered>10</MaxTimesRedelivered> <TimeToLive>60000</TimeToLive> </DLQConfig> </MDBConfig> </proxy-factory-config> </invoker-proxy-binding>
i also change the Quesender on my servlet to:
search.send(tm,DeliveryMode.PERSISTENT, 4, 60000);
from my comsumer (MDB1) ,I now get the JMSExpiration. My problem now is when i force exception to occur and message is delivered to DLQ. Another MDB (DLQMDBean) consumes the message and redeliver to message to queA. I got another JMSExpiration on my (MDB1) not the old JMSExpiration set by the sender(servlet) and when i just use send_buff_info.send(msg) i get "0". how do i get the old JMSExpiration set by my servlet? or im missing something ?
//get connection lookup Context iniCtx = getInitialContext(); QueueConnectionFactory factory = (QueueConnectionFactory) iniCtx.lookup("ConnectionFactory"); Queue queA = (Queue) iniCtx.lookup("queue/SmartQueueA"); conn = factory.createQueueConnection(); session = conn.createQueueSession(false,QueueSession.AUTO_ACKNOWLEDGE); conn.start(); //Send a msgs to queB QueueSender send_buff_info = session.createSender(queA); ObjectMessage mydoc = session.createObjectMessage(); //mydoc.setObject((Serializable) doc); //mydoc.setStringProperty("MessageFormat","FromQueueA"); //send_buff_info.send(msg); send_buff_info.send(msg,DeliveryMode.PERSISTENT, 4, 60000); send_buff_info.close(); conn.stop(); session.close(); conn.close();
It is illegal to throw a RuntimeException from onMessage() read the spec.
The fact that JBoss does its best to handle it, is not going to be portable to
Before you ask messageDrivenContext.setRollbackOnly();
The message sent to DLQ is a copy.
Its only relation to the original message is that it looks similar and a couple
of JBoss specific properties allow you to identity the original message
(which is gone/dead/kaputt/ceased to be).
Thank you once again for the enlightenment. By the way i use messageDrivenContext.setRollbackOnly().
JBoss could copy over the original expiration time from your message as a different property before putting it in the DLQ. If you want the DLQ copied message to expire at the same time as the original, you could make a code change in the JBoss tree. I'm not sure that'd be what most users would expect or want.
Take a look at:
You can also provide the expiration time as part of the user message headers, which do get copied over to the DLQ message.
I agree when you say
You can also provide the expiration time as part of the user message headers, which do get copied over to the DLQ message.. So by changing the TTL on the DLQ the original message expiration increment by what is set in the TTL seconds so the message never get expired. How do i make it the message go, cause in reality this will eat a lot of resources.