[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration

[weston.price@jboss.com]

anonymous wrote : 
  | JBM itself needs it's own DLQ logic since we won't always have JCA. E.g. in the standalone server case. 
  | 

Yep. Makes sense. So I wasn't too far off base.


anonymous wrote : 
  | BTW I'm unclear as to how you keep track of how many times delivery has been attempted in the JCA layer? JMSXDeliveryCount is an optional property not supported by all messaging systems, so if you rely on that your code won't necessary work with other messaging systems.
  | anonymous wrote : 
  |   | 
  |   | The DLQ handler is layered with a JBoss specific handler being called first to handle redelivery. First we check for the existence of the JMS_JBOSS_REDELIVERY_LIMIT and JMS_JBOSS_REDELIVERY_COUNT. If we can find the count we compare it againts the ActivationSpec property DLQMaxResent. If it's over the limit, the JBoss specific DLQ handles the message. 
  |   | 
  |   | If we don't execute the above, the GenericHandler kicks in. We try and check the JMSXDeliveryCount first. If it exists, all is well and we use that as a marker for re-delivery attempts.  
  |   | 
  |   | Now, heres the trick :-). 
  |   | 
  |   | If that property does not exist, we increment a counter based on the cached ID for that message. So, basically in order:
  |   | 
  |   | JBoss specific
  |   | Generic JMSXDeliveryCount
  |   | Cached id/count mapping
  |   | 
  |   | Interestingly enough the two conditions you specify:
  |   | 
  |   | anonymous wrote : 
  |   |   | a) A RuntimeException is thrown from onMessage and ack mode = auto ack or dups ok, retry is immediately attempted (in JBM code). 
  |   |   | 
  |   |   | b) Session gets closed before acking messages so messages are nacked back to the destination. 
  |   |   | anonymous wrote : 
  |   |   |   | 
  |   |   |   | should actually never occur in JCA land for the following reasons:
  |   |   |   | 
  |   |   |   | a) I never propogate a RuntimeException from onMessage. Effectively I trap it and deal with it locally via Transaction demarcation.
  |   |   |   | 
  |   |   |   | b)Sessions are never closed during delivery, only in the case where they have reached an idle timeout, or the adapter itself is being stopped. 
  |   |   |   | 
  |   |   |   | So, effectively it sounds like I am 'jumping in the way' of JBM DLQ. Of course you do redeliver in the case of a commit/rollback on either an XA or local JMS transaction but in this case the JCA DLQ handler would grab it because it is not one of the conditions above. At least that's how I have it in my head. 
  |   |   |   | 
  |   |   |   | 
  |   |   |   | 
  |   |   |   | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986861#3986861

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986861