• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

BEA 8.1 JMS Redelivery + Message Persistence

 
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am looking at implementing JMS Redelivery (timeout and max retries) before a delayed msg is put on another queue. The question I have is:

What is the status of this msg that is being redelivered? I want to delay by up to 10 minutes in some cases and when I tried to browse the queue while the msg is being delayed, it was not there (on the queue)

This means WL must be holding it somewhere. Where is that? memory?
If it is persistent, how would I retrieve it in the event of an outage?

Thank you
Max
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
QueueBrowser is something I wish Sun hadn't bothered to put
in the API because its implementation tends to be pretty
random across vendors.

Any message waiting for delivery should be visible to the
browser, but the problem is that "waiting for delivery"
can be interpreted in different ways by different vendors.
If the server thinks the message isn't eligable for delivery
yet, it is very plausible that you won't see it via the
QueueBrowser. You probably would be able to find it via
Weblogic's JMX service for its queues. JMS is good at
the individual message level, but as a general rule I find
it better to use an API pointed at the queueing system as
a whole when trying to know about anything beyond the
message that was delivered to you.

In the event of an outage the message will still get
delivered to you when things come back up, as long as
you haven't configured the message or queue to do
something different. That is the whole point of using
the JMS API with persistent queued messages. How
the JMS implementation decides on getting you the
message is its problem. You don't "retrieve" it,
JMS delivers it when/where appropriate.
[ January 12, 2006: Message edited by: Reid M. Pinchback ]
 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Reid-

I was able to verify that with JMS redelivery�on WL 8.1 anyway�a persistent message IS stored in file/JDBC until it finally gets successfully taken off the queue. I was confused because the QueueBrowser was not always showing it on the queue�only while JMS was attempting to dequeue the item. I had put a redelivery timeout of 60 seconds and while it was waiting, it was simply in persistent storage�which is fine. As you�ve said, QueueBrowser can be an uncertain implementation. I was using it solely to monitor.
Thanks
Max
[ January 12, 2006: Message edited by: Max Tomlinson ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic