Hi,

Is it possible to configure a message retry interval if i am using the defau
lt messaging server (embedded) in Websphere 6.My MDB's use JCA 1.5 Activatio
n Specs (and not listener ports) , i do see an option to configure Retry cou
nt but not a retry interval
. I also see some recommendations on configuring retry intervals for Listene
r ports but never a configuration if my MDB uses Activation Specifications

Is is possible to do it? If yes, any pointers shall be highly appreciated

If not, any workaround pointers?

Thanks,
Rahul

[ Post a follow-up to this message ]

Unfortunately, I do not believe that the retry interval is configurable on
the default messaging provider/activation specifications.

Hopefully someone else can point you at some workarounds.  The only one I
can think of is for the MDB code to pause before throwing an exception that
would cause the mesasge to be redelivered, but EJBs should not really be
messing with threads and sleeping.

--

Martin Phillips
mphillip at uk.ibm.com


<rahul_mishra02@infosys.com> wrote in message
news:139550606.1185312429303.JavaMail.wassrvr@ltsgwas009.sby.ibm.com...
> Hi,
>
> Is it possible to configure a message retry interval if i am using the
> default messaging server (embedded) in Websphere 6.My MDB's use JCA 1.5
> Activation Specs (and not listener ports) , i do see an option to
> configure Retry count but not a retry interval. I also see some
> recommendations on configuring retry intervals for Listener ports but
> never a configuration if my MDB uses Activation Specifications
>
> Is is possible to do it? If yes, any pointers shall be highly appreciated
>
> If not, any workaround pointers?
>
> Thanks,
> Rahul

[ Post a follow-up to this message ]

Martin Phillips wrote:
> Unfortunately, I do not believe that the retry interval is configurable on
> the default messaging provider/activation specifications.
>
> Hopefully someone else can point you at some workarounds.  The only one I
> can think of is for the MDB code to pause before throwing an exception tha
t
> would cause the mesasge to be redelivered, but EJBs should not really be
> messing with threads and sleeping.
>

One suggestion - presumably the issue is that the item failed in some
way. It's unlikley that just retrying a few seconds or minutes later is
going to make much difference to the problem, so I'd be inclined to dump
all the bad requests into a database table, and then when I'd fixed the
problem to trigger an event, perhaps through a different queue to a
different MDB, to go back and select and re-process the requests. To do
this you might want to use something like asynch beans.

[ Post a follow-up to this message ]

Thanks guys,

well i have considered the option of dumping the data into a table and proce
ssing the way you are recommending..but its like taking matter into my own h
ands..something i was trying to avoid..you guys are right the problem is tha
t MDB is retrying every 1 m
in and even after 5 retries(default)..it is no good..because i need retries 
in the space of a few hours (worst condition)..keep the ideas pouring...hope
fully someone will strike gold

[ Post a follow-up to this message ]

To close this thread

This is what i did..i configured my logical queues to report all failed mess
ages to a newly created exception destination on the bus. To this exception 
destination i gave a physical destination..to which i coded a message consum
er..i invoked my message co
nsumer only when i knew that things were set right, my message consumer list
ened and it did the processing.For my purpose i made the message consumer pu
t the message back on the normal Queue

..this has solved my problem..with very little code..and some amount of con
figuration

[ Post a follow-up to this message ]

It is possible to have a retry interval. Read this article:
http://www.webservertalk.com/archiv...12-1757945.html

Hope this helps.
thx
sst

[ Post a follow-up to this message ]

A couple of Quips in the thread though

1) need to know the support for this propeerty
2)This is available only after 6.0.2, some of my servers are 6.0.1

but that being said this is definitely something to watch out for - strangel
y if i google for this property i have only one result(the link you gave), i
 was expecting some ibm pages.

thanks for the lead though - will try this out

[ Post a follow-up to this message ]