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
