On 17 Aug, 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.
Thats a good point. Lets see what other commes up with. (As side note I
have to say that it seems as if the JMSContainerInvoker stuff will be
tied to JBossMQ untill the new jca 2.0 spec is out. It seems as if no
other vendor have implemented the ASF stuff, and ad to that that the way
we have implemented the ASF stuff is only an interpretation of a non
clear spec. Recent changes in StdServerSession and JMSContainerInvoker
was done due to subtle co-dependecies between the ASF part in JBoss
server and the ASF part in JBossMQ.
But lets walk the code in StdServerSession:
public void run() {
log.debug("running...");
The transaction that is on for a MDB is allways the "first" transaction.
Any bean called from the MDB that do not have bean managed transaction,
no transaction or starts their own will be enlisted in the transaction
started here. Right?
Transaction trans = null;
try {
tm.begin();
trans = tm.getTransaction();
if (xaSession != null) {
XAResource res = xaSession.getXAResource();
trans.enlistResource(res);
if (log.isDebugEnabled()) {
log.debug("XAResource '"+res+"' enlisted.");
}
}
// run the session
session.run();
}
catch (Exception e) {
log.error("session failed to run; setting rollback only", e);
try {
// The transaction will be rolledback in the finally
This is an exception case, lets skip it.
trans.setRollbackOnly();
}
catch (Exception x) {
log.error("failed to set rollback only", x);
}
}
finally {
try {
// Marked rollback
Here is the meat of the matter. The transaction will be marked for
rollback if some of the folloning conditions have been met:
1. System exception thrown in MDB.
2. User exception thrown in MDB.
3. setRollbackOnly() called in MDB.
4. Rollback set in any way in any called bean.
if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK) {
log.info("Rolling back JMS transaction");
// actually roll it back
Problem is here:
Is it not so, that the only way to ack the message (inspite of the fact
that it should be marked as roolback) to actually do a trans.commit()
here.
But this is not possible, since that would also try to commit any faulty
bean, or am I wrong here.
Or is it possible to delist the XAResource, start a new transaction and
make that commit?
In that case we could probably do dead queue handling here.
//Peter
trans.rollback();
// NO XASession? then manually rollback.
// This is not so good but
// it's the best we can do if we have no XASession.
if (xaSession == null && serverSessionPool.isTransacted()) {
session.rollback();
}
} else if (trans.getStatus() == Status.STATUS_ACTIVE) {
// Commit tx
// This will happen if
// a) everything goes well
// b) app. exception was thrown
trans.commit();
// NO XASession? then manually commit. This is not so good but
// it's the best we can do if we have no XASession.
if (xaSession == null && serverSessionPool.isTransacted()) {
session.commit();
}
}
}
catch (Exception e) {
log.error("failed to commit/rollback", e);
}
StdServerSession.this.recycle();
}
log.debug("done");
}
>
> ----- 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
--
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
