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
