-
1. Re: setJMSExpiration() dont seem to work
adrian.brock Apr 20, 2004 3:21 AM (in response to jmer)docs/dtd/jboss_3_2.dtd
DLQConfig/TimeToLive -
2. Re: setJMSExpiration() dont seem to work
jmer Apr 20, 2004 5:00 AM (in response to jmer)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();
Many thanks;
jmer -
3. Re: setJMSExpiration() dont seem to work
adrian.brock Apr 20, 2004 11:23 AM (in response to jmer)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
other servers.
Before you ask messageDrivenContext.setRollbackOnly(); -
4. Re: setJMSExpiration() dont seem to work
adrian.brock Apr 20, 2004 11:25 AM (in response to jmer)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). -
5. Re: setJMSExpiration() dont seem to work
jmer Apr 20, 2004 8:14 PM (in response to jmer)Thank you once again for the enlightenment. By the way i use messageDrivenContext.setRollbackOnly().
-
6. Re: setJMSExpiration() dont seem to work
genman Apr 20, 2004 11:39 PM (in response to jmer)
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:
server/src/main/org/jboss/ejb/plugins/jms/DLQHandler.java
You can also provide the expiration time as part of the user message headers, which do get copied over to the DLQ message. -
7. Re: setJMSExpiration() dont seem to work
jmer Jul 22, 2004 9:04 PM (in response to jmer)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.