[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration
by timfox
I don't get it.
How can you handle the exception if we catch it in our layer so it never bubbles up to you?
Here is the code:
|
| catch (RuntimeException e)
| {
| long id = m.getMessage().getMessageID();
|
| log.error("RuntimeException was thrown from onMessage, " + id + " will be redelivered", e);
|
| // See JMS 1.1 spec 4.5.2
|
| if (ackMode == Session.AUTO_ACKNOWLEDGE || ackMode == Session.DUPS_OK_ACKNOWLEDGE)
| {
| // We redeliver a certain number of times
| if (tries < maxDeliveries)
| {
| tries++;
| }
| else
| {
| log.error("Max redeliveries has occurred for message: " + m.getJMSMessageID());
|
| //postdeliver will do a cancel rather than an ack which will cause the ref to end
| //up in the dlq
|
| cancel = true;
|
| break;
| }
| }
| else
| {
| // Session is either transacted or CLIENT_ACKNOWLEDGE
| // We just deliver next message
| if (trace) { log.trace("ignoring exception on " + id); }
|
| break;
| }
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986933#3986933
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986933
19 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration
by weston.price@jboss.com
Put another way:
If an EJB developer wants DLQ functionality for an MDB, he/she has to use the JMS/JCA DLQ implementation. Since we have made the decision to always execute message delivery in the context of a transaction (local or XA), JBM would not handle the case where a RuntimeException occurs. It would simply ignore the message and move on.
While the JMS spec makes note that RuntimeExceptions should not occur in MessageListeners, EJB(X) does not make this assumption. The spec even goes so far as to *require* that message be redelivered depending upon the transaction attributes.
For CMT/REQUIRED MDB's the choice is easy, the specification requires that the transaction be rolled back and the message be redelivered. For BMT/CMT-NOT_SUPPORTED, the spec is all but useless. Effectively the MDB executes in an 'unspecified transaction context'. There are no restrictions on how the container/JCA/integration layer can handle this situation but there are also no real guidlines unfortunately.
Of course for a standalone JBM deployment, the situation is much different; at that point it's just plain ole JMS ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986923#3986923
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986923
19 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration
by weston.price@jboss.com
anonymous wrote :
| You mean JBoss MQ specific? JBoss Messaging doesn't have these properties.
|
I wondered about this. Based on this, the JMSXDeliveryCount will be consulted first and then the cached id in attempting to determine if the message should be sent to the DLQ. Effectively with JBM, no JBoss specific properties are consulted.
anonymous wrote :
| If a RuntimeException is thrown from onMessage and the session is transacted it is ignored as per JMS spec and delivery of the next message continues.
|
>From the JMS spec:
anonymous wrote :
| Transacted Session - the next message for the listener is delivered. The client
| can either commit or roll back the session (in other words, a
| RuntimeException does not automatically rollback the session).
|
This is what we do, with the default behavior being that a rollback occurs. This can be altered via an ActivationSpec property to simply commit the message in the case of a RuntimeException when the transaction attribute of the MDB is BMT or CMT with NOT_SUPPORTED. CMT/REQUIRED is always rolledback and redelivered as per the EJB spec.
anonymous wrote :
| Perhaps we should have an option to turn off JCA dlq functionality if we know the provider supports its own? Should this be the default?
|
You can already do this it's a simple property (useDLQ) of the JMSActivationSpec.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986911#3986911
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986911
19 years, 4 months