[
https://jira.jboss.org/jira/browse/JBAS-7465?page=com.atlassian.jira.plug...
]
Adrian Brock commented on JBAS-7465:
------------------------------------
How is this a bug report? It is operating as expected.
If somebody wants help configuring an MDB/DLQ then the forums
are the correct place if they can't be bother to read the manual.
1) It is not the job of JCA to look at a particular jms product's queue
configuration.
If the jms product wants to override the value, it can do so at the message level using
the property
JMS_JBOSS_REDELIVERY_LIMIT. There is no standardised property for this.
If the jms product has some other property, then you can "write your own"
DLQHandler to look at it.
However, if the jms product already supports DLQ processing then you should disable
the DLQ processing in the MDB. i.e. useDLQ=false.
It is duplicate work and not as "reliable" as the jms product handling
internally, e.g.
if the jms connection breaks between sending the message to the DLQ and ACKing the
dead message, you'll eventually end up with the message twice in the DLQ.
The feature only exists because JBossMQ did not have internal DLQ processing.
2) It is called the "max REDELIVERY count", i.e. it will deliver the message
once then do a maximum number of redeliveries for a total 1+DLQMaxResent. This
configuration has been this way since jboss-2.4.x
3) See (1)
Some issues with JCA's DLQ handling
-----------------------------------
Key: JBAS-7465
URL:
https://jira.jboss.org/jira/browse/JBAS-7465
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JCA service
Reporter: Howard Gao
Assignee: Jesper Pedersen
1. JCA ignores the DLQ attribute specified in the queue's configuration file.
2. JCA doesn't correctly handle the max redelivery limit. If the limit is set to n,
it doesn't send the message to DLQ until n+1 th redelivery.
3. JCA doesn't correctly handle its relation with JBM's max re-delivery control.
Problems will show if you specify the DLQMaxResent count to be greater than JBM's
default (10), in which case JBM will send the message to DLQ always at 10th re-delivery,
giving JCA no chance to control.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira