dcsimg
AUTO_ACKNOWLEDGE Message Driven Beans and Session Beans
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   David_Allen
Posted On:   Monday, June 30, 2003 12:24 AM

I have a Message Producer that creates a QueueSession with AUTO_ACKNOWLEDGE as the acknowledgement mode. When a message is received, a Message Driven Bean will partition work off to another component depending on the message type. One component in particular is a Session Bean used to FTP a file. If the file transfer fails, i would like to wait for 15 minutes before re-trying. I don't want to hold on to a MDB instance while waiting to re-transfer the file, and from what i have read, it isn't recommended to start threads in the EJB Container. I would like to do something like this: onMessage 1: Determine message type, 2: Call the appropriate helper class/Session Bean, and 3: Return witho   More>>


I have a Message Producer that creates a QueueSession with AUTO_ACKNOWLEDGE as the acknowledgement mode. When a message is received, a Message Driven Bean will partition work off to another component depending on the message type.

One component in particular is a Session Bean used to FTP a file. If the file transfer fails, i would like to wait for 15 minutes before re-trying.

I don't want to hold on to a MDB instance while waiting to re-transfer the file, and from what i have read, it isn't recommended to start threads in the EJB Container. I would like to do something like this:

			
onMessage
1: Determine message type,
2: Call the appropriate helper class/Session Bean, and
3: Return without waiting.


Can anyone help?

Also, can someone tell me when an AUTO_ACKNOWLEDGE message is actually acknowledged? Is it as soon as the message is retrieved, or when onMessage has completed successfully?

Thankyou!
   <<Less

Re: AUTO_ACKNOWLEDGE Message Driven Beans and Session Beans

Posted By:   Nick_Maiorano  
Posted On:   Monday, June 30, 2003 08:31 AM

David,



You can create a retry queue where you can place all of your failed messages. The key here is that this queue must not have any consumers attached to it until you are ready to retry.



You also need to use a timer service (either JMX or the new timer service available in EJB 2.1) to callback an object that will connect to this retry queue. However, you cannot use an MDB because they are always connected to the queue while you need a consumer that is occasionally connected. You can just create a POJO queue consumer that simply pulls from the retry queue and re-injects the messages into the original queue. Then, it must disconnect from the queue to allow new failed messages to linger for 15 minutes.

About | Sitemap | Contact