Didn't someone mention a while ago about some WL feature that had a
configurable delay for message redelivery to a MDB. We could implement this
to avoid spinning (too fast) and put the dead queue stuff into JBossMQ, so
that when JBoss is using JBossMQ it will use the dead queue semantics and
with others (why?) it would simply wait a configured time before redelivery.
--jason
On Fri, 17 Aug 2001, Scott M Stark wrote:
> Maybe it should be handled by JBossMQ. The downside to this is that were
> relying on non-spec defined behavior at the JMS provider level to ensure
> that
> the JBoss MDBs behave well.
>
> ----- Original Message -----
> From: "Peter Antman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, August 16, 2001 11:30 PM
> Subject: Re: [JBoss-dev] Improving MDB behavior in the presence of delivery
> failures
>
>
> >
> >
> > Hi,
> > MDB:s may throw execeptions. They may throw spec compliant exception, if
> > I understand the spec correct, that is: an MDB should not thow
> > application exception or runtime exceptions, but it may throw system
> > exceptions, for example: EJBException.
> >
> > They may ofcourse throw the not spec compliant exceptions to, even if
> > this is a bug it is still something we have to handle.
> >
> > Two things will basically happen today:
> >
> > - If container managed the container transaction will be marked for
> > rollback.
> > - The message will not be acked.
> >
> > I do agree with the view that we should have some sort of dead queue,
> > where faulty messages is everually placed, but I am not that shure that
> > this is a MDB thing, to mee it more seems like a JMSProvider thing.
> >
> > This could be done it two ways (which might be combined)
> >
> > - JBossMQ has a default dead queue where it places messages that are not
> > acked after a configurable amount of tries.
> >
> > - Each destination may have a configurable dead queue.
> >
> > It also sees easier for the provider to keep a record of how many times
> > it has tried a particular message, than to build that feature into the
> > StdServerSession (because that is where the dead queue stuff would have
> > to go, because that is where we handle message receipt - to place
> > something a a dead queu for the JMSContainerInvoker will mean that it
> > have to acknowledge the message, inspite of the transaction beeing
> > marked for rollback, but without effecting any other beans that are also
> > dependant on the transaction.)
> >
> > Or does this defeat reliability contract of JMS?
> >
> > (From the Oreilly Java Messaging Service book, page 125 I get it that
> > the normal solution is that the provider provides a "Dead Letter Queue",
> > where messages that have expired, or "viewed by the provider as
> > udeliverable due to some other reason".
> >
> > To me this suggests that this is a JBossMQ problem. One way to ease the
> > burden on the server would be if messages marked for redelivery would
> > first go into an algorithm that slows down delivery. Wait one second,
> > try, wiat 10, try, wait 20, try... and eventually place it in a "Dead
> > Letter Queue".
> >
> > Or am I totally of here?
> >
> > //Peter
> >
> >
> > On 16 Aug, Scott M Stark wrote:
> > > The mdb does not have to thrown an exception to cause this behavior. If
> it
> > > interacts with another ejb that is transacted and that bean rolls the
> > > transaction
> > > back the msg will get redeliverd. I have a trivally test case that
> causes
> > > the problem:
> > >
> > > public void onMessage(Message m)
> > > {
> > > try
> > > {
> > > IHome home = ...;
> > > home.findByPrimaryKey(null);
> > > }
> > > catch(Throwable t)
> > > {
> > > }
> > > }
> > >
> > > The tx will be rolled back by the failed findByPrimaryKey() call which
> will
> > > cause the msg
> > > to be redelivered and were spinning.
> > >
> > > ----- Original Message -----
> > > From: "Hiram Chirino" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, August 16, 2001 6:28 PM
> > > Subject: Re: [JBoss-dev] Improving MDB behavior in the presence of
> delivery
> > > failures
> > >
> > >
> > >>
> > >> Per spec the MDB should not be throwing any exceptions.. This would
> mean
> > >> that it's thier responsibility to put the message to a 'rejected'
> queue.
> > >>
> > >> But I think that is the best solution would be to allow the MDB to be
> > >> configured with the 'rejected' queue in it's deployment descriptor. I
> > > know
> > >> that not everybody will enclose thier MDB code in try { } catch
> (Throable
> > > e)
> > >> {}
> > >>
> > >>
> > >> Regards,
> > >> Hiarm
> > >>
> > >> >From: "Scott M Stark" <[EMAIL PROTECTED]>
> > >> >Reply-To: [EMAIL PROTECTED]
> > >> >To: <[EMAIL PROTECTED]>
> > >> >Subject: [JBoss-dev] Improving MDB behavior in the presence of
> delivery
> > >> >failures
> > >> >Date: Thu, 16 Aug 2001 18:22:23 -0700
> > >> >
> > >> >Right now there are any number of ways to cause JBoss to spin in a
> tight
> > >> >loop
> > >> >trying to deliver a transacted msg to an mdb due to a problem with
> either
> > >> >the msg or mdb code that either causes an exception thrown from
> > > onMessage()
> > >> >or the tx to be rolled back. A trivial example of the latter is to
> have
> > > an
> > >> >mdb
> > >> >do a findByPrimaryKey() using a key from the msg that happens to be
> null.
> > >> >
> > >> >One solution would be to have the mdb container fail such msgs after
> so
> > >> >many delivery attempts. On failure, the msg along with the exception
> > > would
> > >> >be placed into a error queue associated with the container. An admin
> > > would
> > >> >have to pull the msg off, fix any data problems and then place the msg
> > >> >back onto the mdb queue/topic for redelivery.
> > >> >
> > >> >Are there any better ways to handle this?
> > >> >
> > >> >
> > >> >
> > >> >_______________________________________________
> > >> >Jboss-development mailing list
> > >> >[EMAIL PROTECTED]
> > >> >http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >>
> > >>
> > >> _________________________________________________________________
> > >> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
> > >>
> > >>
> > >> _______________________________________________
> > >> Jboss-development mailing list
> > >> [EMAIL PROTECTED]
> > >> http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >>
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> > --
> > Jobba hos oss: http://www.tim.se/weblab
> > ------------------------------------------------------------
> > Peter Antman Technology in Media, Box 34105 100 26 Stockholm
> > Systems Architect WWW: http://www.tim.se
> > Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
> > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
> > ------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
